Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
On Saturday 05 January 2019, Markus wrote: > > I'm aware of this. I just wanted to be be sure that i don't introduce > a tag that overlaps with the definition of another OSM tag – in this > case natural=cape. But as natural=cape has almost exclusively been > used for costal extreme points, there doesn't seem to be an overlap, > even without the requirement of an isthmus. Yes, de facto use of natural=cape was at least until recently for a very narrow set of features. And it would be good for data quality if that would stay this way. Therefore it is good if there is an alternative in the form of natural=peninsula that can be used by mappers who want to map something that might be called a 'cape' or some similar term in a different language but that is not a natural=cape for OSM. Accordingly it would be good if the suggestion is not: Use natural=cape for capes and natural=peninsula for peninsulas but if there is an discerning abstract definition that is language independent. As written on the wiki natural=cape is essentially: * seen from water: landmark at the coast to circumnavigate * seen from land: coastal extreme point on land in a certain direction What you will probably need to consider is how to distinguish natural=peninula from named parts of the coast or named coastal areas and if you want to include more specific coastal land forms like spits. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
On Friday 18 January 2019, Markus wrote: > [...]particularly the > distinction from natural=cape. natural=peninsula now includes a > minimal area limit of 1 km². That is a very bad idea on two accounts: * it would to my knowledge be a first in the whole OSM tagging system that defines a tag through an arbitrary numerical limit. And a pointless limit i would like to add because any data user who wants to filter for peninsulas larger than one square kilometer could do so just as well (or with as much difficulty) as the mapper. * it would dilute the meaning of natural=cape from its current very narrow meaning to one of "what natural=cape currently means plus small peninsulas" which would not only be counterproductive for data quality, it would also be completely counter-intuitive for the mapper (tagging a cape and a 0.9 km^2 peninsula the same but tagging a 0.9 km^2 peninsula and a 1.1 km^2 peninsula differently) -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
On Friday 18 January 2019, Paul Allen wrote: > > * it would to my knowledge be a first in the whole OSM tagging > > system that defines a tag through an arbitrary numerical limit. > > place=islet and place=island. Islets are smaller than 1 km², islands > are larger than 1 km². I stand corrected. If you look at the size distribution of features with those tags you will see that the distinction between place=islet and place=island does not have any practical meaning in the data. In other words: If you want natural=cape and natural=peninsula to be synonyms for natural=cape_or_peninsula and don't mind flushing >11k existing natural=cape features with a well defined meaning which are not peninsulas down the drain such a limit could help accomplishing that. > place=hamlet, typically less than 100-200 inhabitants. > > place=village, typically 1,000-10,000 inhabitants. Where is the numerical limit in there? -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
On Saturday 19 January 2019, Markus wrote: > > An arbitrary and absolute limit is not ideal and i actually don't > like it very much, but the only other solution i see is to abandon > natural=cape and map all > points/capes/headlands/promontories/peninsulas with one single tag, > whether it be natural=peninsula or another tag. Maybe that's even the > better solution. As i have said natural=cape has a well defined and consistently applied meaning in OSM so far. Unless you want to destroy that you should aim at defining natural=peninsula in a way does not mess with definition of natural=cape. I see no problem with that. The problem i see is - as previously mentioned - defining natural=peninsula in a way that makes it mean something more specific than 'some named land area at the coast'. But that problem is completely unrelated to natural=cape. > By the way, i measured a few dozen of > points/capes/headlands/peninsulas of Brittany. Most either have an > area of about 0.1–0.5 km² (they are usually called pointes 'points') > or > 1.5 km² (called capes 'capes' or presqu'îles 'peninsulas'), so > the 1 km² limit doesn't seem to be that bad, but could also be > halved. Frankly i don't even remotely follow your argument here. Maybe it would help if you could tell me how to determine the area of the capes i previously used as examples: https://www.openstreetmap.org/node/32532727 https://www.openstreetmap.org/node/2510985983 https://www.openstreetmap.org/node/2098928265 https://www.openstreetmap.org/node/4727612495 https://www.openstreetmap.org/node/2696775247 -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
On Saturday 19 January 2019, Markus wrote: > > > Frankly i don't even remotely follow your argument here. Maybe it > > would help if you could tell me how to determine the area of the > > capes i previously used as examples: > > I've never visited any of these capes and thus can't tell you if the > names only refer to a point or to a (fuzzy) area. But, as another > example, the Pointe de Pen-Hir [1], which is a headland forming a > coastal extreme point, refers to an area of about 0.3 km². And how do i as a mapper practically determine the area of Pointe de Pen-Hir to be about 0.3 km^2? -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
On Saturday 19 January 2019, Markus wrote: > > If natural=cape doesn't mean a headland forming a coastal extreme > point, then i fail to understand what natural=cape does mean. Does it > only mean the extreme point of a headland? Are there really names > that only refer to a point? Isn't it rather a fuzzy area that the > name refers to? I don't know what you understand 'headland' to mean here. The current meaning of natural=cape i described in a previous mail as: > * seen from water: landmark at the coast to circumnavigate > * seen from land: coastal extreme point on land in a certain > direction -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
On Monday 21 January 2019, Markus wrote: > > I've improved the differentiation from natural=cape and abandoned the > minimal area requirement of 1 km². Please tell me if it makes sense > now. That looks better though this might still be read as there being necessarily a 1:1 relationship between a natural=cape and a natural=peninsula (and your illustration therefore showing Pointe des Espagnols but not Pointe des Capucins). -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
On Saturday 19 January 2019, Markus wrote: > > And how do i as a mapper practically determine the area of Pointe > > de Pen-Hir to be about 0.3 km^2? > > By mapping the area the name Pointe de Pen-Hir refers to as area: > > https://master.apis.dev.openstreetmap.org/way/4305300517#map=15/48.26 >07/-4.6146 And how can a mapper practically determine this geometry? It seems to me that you are conjuring a peninsula here and simply apply the name of the cape to the peninsula without a basis for making that connection. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
On Saturday 19 January 2019, Markus wrote: > > > > I don't know what you understand 'headland' to mean here. > > A piece of land that projects into a body of water. Sounds like a peninsula to me. In case that is still unclear: A natural=cape feature is sometimes located on a peninsula - but it does not have to be. And there can be multiple natural=cape on the same peninsula - famous example are Cape Point and Cape of Good Hope on Cape Peninsula. And there are plenty of capes located nowhere near what you might classify a peninsula (several of my original samples are such cases). -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tourism=attraction: feature or secondary tag?
On Wednesday 05 December 2018, Joseph Eisenberg wrote: > [...] > > This is reasonable; many features can be of interest to tourists, and > tourism=attraction doesn't provide much information. Is it an area of > shops? A beach? A theme park? A historic monument? > > However, there is a preset in the JOSM editor that allows > tourism=attraction to be used as the top-level tag. > > Is it necessary to use tourism=attraction as the only tag for certain > features? Well - the main problem with tourism=attraction is that it has no consistent application hence no real meaning as a tag so you can't really say if it is a standalone tag or not. What you can say is that: * it is widely used as the only characterizing tag of a feature (usually just tourism=attraction + name). * it is not a verifiable tag in either variant, the closest you could interpret it to mean is indicating some kind of wikipedia-like notability. * it is often used as a 'lazy tag' - i.e. used by mappers who did not want to look for or to invent a more meaningful characterization. > (Currently, tourism=attraction alone is rendered only as a name label > on the Openstreetmap-carto style, without an border, area colour or > icon. Either we need to add an icon or outline, or we can remove this > from the list of rendered features. If the wiki is correct then it > can be removed, because properly-tagged features should have another, > more specific tag that can be rendered) It would certainly be good to stop rendering it to incentivize mappers to choose more meaningful tags instead but it also should be said that this is essentially a case of 'damage done' - the tag is already meaningless, stopping to render it would help better tagging in the future, it would not in any way add meaning to the tag as it is already used. We have however many other tags where OSM-Carto recently added or changed rendering in ways that provide mapping incentives agaist the established meaning of the tags. This and the resulting dilution of existing value and precision in OSM data is going to be a much bigger problem. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tourism=attraction: feature or secondary tag?
On Friday 07 December 2018, Mateusz Konieczny wrote: > > We have however many other tags where OSM-Carto recently added or > > changed rendering in ways that provide mapping incentives agaist > > the established meaning of the tags. > > Can you link issues opened on issue tracker that > report this serious problems? > > I looked at it and I failed to find any that would be opened > recently. I have not recently followed all of the changes and i mostly stoppend reporting problems i see because when i did so these comments were universally dismissed and had no influence. The changes i refer to with my comment are in particular the inflationary addition of new POI symbols many of which have been chosen without considering the applicability to represent the feature type in question across different cultures and different geographic settings. Many of these represent just the European urban cliché version of it. The other group of changes i had in mind is the abuse of way_area filtering as an universal cartographic importance rating, in particular for point label placement. The resulting initiatives of label drawing through non-verifiable polygon painting can be observed right now. And tourism=attraction was one of the first tags to follow this principle in OSM-Carto so it is kind of a forerunner in that regard. I don't really see much of a chance of a change in direction here (in other words: it will likely get worse before it maybe gets better) but i none the less consider it important to point out that this is something that is visible right now to people who approach this with an open mind and open eyes. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tourism=attraction: feature or secondary tag?
On Thursday 06 December 2018, Yves wrote: > tourism=attraction can be added to a lot of features indeed, that's > why I think the label rendering in OSM-carto is a good idea because > you will probably never find a common rendering to encompass this > variety. Your desire for this is somewhat understandable - but this clashes with the current documented goals of OSM-Carto and the aim of OSM to map the verifiable geography and not subjective opinions. > But on another topic, where does the idea of 'primary' and > 'secondary' tags I read here and there and more and more often comes > from? Are we making a map of the world in its complexity or what? > Yves Secondary tags refers to tags that have no distinct meaning on their own. Think of a feature that has an 'access=no' tag or an 'intermittent=yes' tag and no other tags - these do not make any sense on their own, the only get meaning together with other tags (like a highway or waterway tag in these cases). -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
On Saturday 17 November 2018, Daniel Koc4� wrote: > > The problem is that I have asked you how to draw verifiable node, > [...] No, you have not, you have asked: > It would be much more useful if you tell now how to verify position > of this node? And i told you exactly that. We all know you think bays and straits should best be mapped with polygons and that it is a positive thing to steer mappers to doing that (which by the way is against the goals of OSM-Carto even if your opinion on this has merit). You can try to justify that all you want - this does not change anything about the argument i gave against it - that the polygon drawing almost never adds any verifiable information on the geographic reality compared to a node or a linear way representation. I know i will not change your opinion on this - countless non-successful discussions with you on much clearer and simpler matters have shown me that. I can just hope most mappers will emancipate themselves from this and not invest their time and energy in mapping and maintining polygon mazes over coastal waters. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
On Saturday 17 November 2018, Frederik Ramm wrote:
>
> I do agree that while we should not "map for the renderer" it is good
> to have a central map that provides valuable feedback, and keeps
> mappers from, say, introducing random highway types by simply not
> rendering them. But I felt in this situation, they had overstepped
> their mandate, *especially* because they were not reacting to
> something that people were doing, but actively creating a new feature
> ("hey, you can now have huge named bays") and at the same time adding
> the data to OSM to illustrate their new feature.
Indeed.
And to make this very clear once again - no one suggested so far to
universally disallow mapping bays using polygons.
What has been said is that mapping bays with a node is the most common,
most widely accepted and (in my opinion) in the vast majority of cases
the most suitable way of mapping bays, in particular larger ones. And
OSM-Carto should support mappers in this practice and not steer them to
change it.
OSM-Carto has historically for as long as i can remember supported nodes
and polygons equally for features where both variants are commonly
accepted methods to map something - housenumbers is the most prominent
example probably - which can be mapped both on an address node or on a
building and are shown in both cases with no preference for either of
them. The same is perfectly appropriate to do for bays. What however
is not appropriate is to incentivize mapping bays with polygons by
labeling them from polygons in a different form that in particular for
large bays is more suitable and attractive than when mapped with nodes.
Or like for straits to label them when mapped with polygons but not
show them at all when mapped with a linear way.
--
Christoph Hormann
http://www.imagico.de/
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
On Saturday 17 November 2018, Kevin Kenny wrote: > The discussion of indefinite objects falls in the same category in my > mind. We shouldn't have to discard what is known or defined about an > object because some other part of the object is unknown or > indefinite. As we say in German: Umgekehrt wird ein Schuh draus. You should not need to add non-verifiable data to the database to be able to map verifiable knowledge of the geography and see it in OSM-Carto. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
On Saturday 17 November 2018, Kevin Kenny wrote: > > This request also has nothing to do with relations that are large > enough to break the tools. I'm confining my request here to features > that are relatively small in extent - perhaps up to a few tens of km > on a side. Maybe with all disagreement we have a possible partial conclusion here where most of us can agree on: That bays and straits above a certain size - be that a few tens of km or even 100-200km - should not be mapped with a polygon. As Frederik explained there are very good arguments for that even without taking into account the verifiability question. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
On Thursday 10 January 2019, Tomas Straupis wrote: > > In order to have correct labelling you need polygon geometry for > peninsulas (as well as for other objects), [...] Just for the record: This is not correct (discussed plenty of times in the past, no need to repeat). Note the proposal from Markus is so far not indicating preferences on node vs. polygon apart from verifiability concerns. This part of the discussion is about if the proposal should discourage mapping large peninsulas with polygons for practical reasons of ease of mapping and maintainability of the data. I think this would be a good idea but i also doubt this would prevent some mappers to push such mapping. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Allotments plot / lot tagging and ref?
On Monday 07 January 2019, Joseph Eisenberg wrote: > The current wiki page for landuse=allotments > (https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dallotments) states > that one should "Use allotments=plot and/or boundary=lot for an > individual plot and lot=number_of_plot for number of plot." > > However, the wiki page for allotments=plot > (https://wiki.openstreetmap.org/wiki/Tag:allotments%3Dplot) states > "You may want to use the ref=* to indicate the number assigned to > your plot." I am wondering about the practical verifiability of such numbers. I mean in OSM we do not map internal numbering systems of organizations for their infrastructure if those are not manifested in the form of signs visible to the outside observer. If plot numbers are signed the question is why these are not considered addresses. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Allotments plot / lot tagging and ref?
On Monday 07 January 2019, Paul Allen wrote: > > They are verifiable by asking the organization in charge of the > allotments, as I initially did > when mapping some allotments. Verifiability in OSM means *independent* verifiability based on observations of the geographic reality. Same as with any other kind of proprietary ID. > How about because allotments do not have postcodes? That might depend on the country but AFAIK in many countries postal codes cover the whole country. > How about > because addresses are > generally a means of figuring out where to deliver physical mail and > allotments are not on > postal delivery routes? There are many addresses that do not receive postal delivery - in particular for example corporate infrastructure where mail is collectively delivered to a single location while individual buildings and other infrastructure still have their own addesses. > Even addr:unit would be stretching the > definition of unit past its breaking > point. I have not made any suggestion as to what kind of address tag to use but if the plot number is signed and you invite your friends for a grilling party at plot 42 that is definitely an address from my perspective. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
On Thursday 10 January 2019, Markus wrote: > > I've replaced *nearly surrounded by water* with *surrounded by water > on the majority of its border*, but i'm unsure whether this is > clearer. If you or someone has a better idea, please tell me. That is a fairly toothless criterion because you will very often be able to achive this simply by mapping the coastline in more detail (making it longer). A more robust and tighter criterion would be that the length of the non-water part of the boundary needs to be shorter than the square root of its area. Geometrically this limit is equivalent to a square shaped peninsula connected at one of its sides. Ultimately any such criterion is an arbitrary limit of course. Practical examples of things frequently called peninsulas that exceed this limit are the Balkan Peninsula: https://en.wikipedia.org/wiki/Balkans and the Indian subcontinent: https://en.wikipedia.org/wiki/Indian_subcontinent But i think if you really want natural=peninsula to be meaningful geometrically you need to go at least to this limit. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
On Wednesday 09 January 2019, Markus wrote: > > > > * seen from water: landmark at the coast to circumnavigate > > * seen from land: coastal extreme point on land in a certain > > direction > > Couldn't 'a point to circumnavigate' lead to confusion because > peninsulas needs to be circumnavigated too? I don't know - that depends on how you want to define natural=peninsula. In classic navigation you use landmarks at the coast to plot and verify your course. That is what is meant with the above. > Isn't this clear by definition? The current definition of > natural=peninsula is 'a piece of land nearly surrounded by water or > projecting into water from a larger land mass' while a coastal area > is longish. As you can see the concept of 'nearly' is pretty vague here. The description for bays uses the term 'mostly' and look what this has led to: https://www.openstreetmap.org/relation/4681569 https://www.openstreetmap.org/way/552099079 https://www.openstreetmap.org/relation/8399350 So if you want natural=peninsula to mean something more specific than 'some named land area at the coast' (like bay tagging on polygon meanwhile just means 'some water area near the coast a mapper wanted to label') you better try to make the definition somewhat clearer. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Facts and opinions
On Wednesday 09 January 2019, Bryan Housel wrote: > [...] Most of the people involved don’t even work on > software. Despite accurate critique of dysfunctional dynamics and developments on the wiki i smell a software development supremacist here. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – natural=peninsula (Was: Feature Proposal – RFC – place=peninsula)
On Wednesday 09 January 2019, Frederik Ramm wrote: > > on second thought, if the Iberian Peninsula is already a Peninsula, > does that invalidate all Peninsula claims on land masses protruding > from it, or can there be cascading Peninsulas? Of course, and you can measure the level of completeness in mapping by how many bays and peninsulas a coastline segment is member of. If only someone would have warned us about this years ago... Oh wait, someone did: https://lists.openstreetmap.org/pipermail/tagging/2014-October/019780.html -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Watershed or Drainage Basin relation draft proposal
On Thursday 13 September 2018, Joseph Eisenberg wrote: > Relations of type=watershed are currently used over 2000 times and > there is a descriptive Wiki page but no proposal. ( > https://wiki.openstreetmap.org/wiki/Relation:watershed) > > It would be useful to have a relation that showed drainage divides > (aka watersheds) and drainage basins (the network of streams and > rivers draining into a water body or waterway) Watershed divides are an abstract non-physical concept that is generally not verifiable in practical mapping - there are cases where they are (because they evidently coincide with physical features like ridges) but there are huge parts of the world where they are not and you would only try to estimate them based on already existing data. In short: This is not something you can reasonably map in OSM. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Watershed or Drainage Basin relation draft proposal
On Thursday 13 September 2018, Joseph Eisenberg wrote: > Christoph, > So you believe the ridges are verifiable (and the network of > waterways, I assume), but potentially parts of the watershed would > not be verifiable because eg. terrain is too flat? There are many reasons why a the watershed structure can be practically non-verifiable on the ground. Relatively flat topography is only one of them. I would estimate that at least about 40 percent of the Earth land surfaces have a drainage structure that is practically non-verifiable (in the sense that independent estimates from several mappers would not converge to the same geometry). The percentage would be even higher if you want it to be verifiable through remote mapping. > I was thinking > that in fairly flat areas it is still possbile to see which way water > flows in drainage channels, and it's often possible to find the > highest line throught he terrain when surveying. Nothing speaks against mapping physically observable features like drainage channels but mapping additional abstract geometries derived from them in OSM makes little sense IMO. Note in flat areas with artificial drainage channels the actual drainage structure can be extremely complex. > Would these examples be verifiable? > > [...] Not having first hand knowledge of these cases means i can't really tell. A waterway is a geometry directly physically observable on the ground. The watershed divide is an abstract geometry OTOH. You see a ridge and *assume* that water from one side of the ridge flows into a certain drainage system and on the other side it flows into a different one. But you don't observe this. You might have a simple case where this seems obvious but the fundamental problem is still there. In humid climate areas you can make the mapping more reliable by first diligently mapping the waterway network in the whole area but then what is the point in mapping the watershed divides in addition? Also note in priciple watersheds form an infinitely deep hierarchy of geometries. To be able to practically map these you would have to define a discretization system in this hierarchy which would be an arbitrary up-front decision with no basis in the physical world. > I value your opinion Christoph, because I hoped this relation might > encourage more complete mapping of ridges, watersheds and drainage > basins, thus making it easier to render good maps, eg > http://www.imagico.de/map/water_generalize_en.php If you want to facilitate better maps w.r.t. hydrography the best way would be to put all the time and energy you might put into mapping watersheds into mapping the waterway network. Priorities should be: * correct connectivity * correct distinction onto artificial and natural * correct flow direction * completeness and unifomity in detail of mapping Where these conditions are fulfilled processing the waterbody data for accurate maps is orders of magnitude easier than elsewhere. Compared to that the would-be gain of having watershed geometries available in addition would be relatively small. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping language borders, tagging offical languages?
On Friday 14 September 2018, Joseph Eisenberg wrote: > > Christoph (@Imagico) has suggested tagging the official language > information on administrative boundary relations: > http://blog.imagico.de/you-name-it-on-representing-geographic-diversi >ty-in-names/ A few remarks here regarding this: * the choice of suggesting tagging the language information on either the administrative boundary relations or the individual features but not on any other feature with a meaning beyond the feature itself was not arbitrary. Limiting this to a well defined data basis and simple rules (here: individual feature tag and administrative unit as fallback, priority through admin_level) is a necessary prerequisite for any chance of practical use. And if you look at what systematics are used for the name tags at the moment the vast majority of choices happens on administrative units with admin_level 2-4. * the choice of tagging the locally preferred form of showing the names and not any culture specific classification into things like "official", "primary", "indigenous", "main" or "majority" was also deliberate because this seems to be the approach that least imposes a specific cultural understanding of languages onto people. * keep in mind the very idea behind this proposal is that data users have the free choice to either use the language format information in the data as is or replace or modify it with any other information. So any discussion along the lines of "i want to base the language format on some non-verifiably spatial division" is unnecessary because you obviously can always do that, you just can't have and maintain such data inside of the OSM database. * the choice of syntax for the language string is something that can be discussed obviously. You can essentially use any characters that are unlikely to occur in an actual format as structuring elements. The dollar sign is a common symbol prefix here. * the core of my proposal is not using the plain "name" tag any more for anything other than legacy fallback if other data is missing. Any proposal to separately tag the language of the name tag (several initiatives in that direction have been made in the past) is a very different idea. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping language borders, tagging offical languages?
On Saturday 15 September 2018, Martin Koppenhoefer wrote:
>
> please let us not use "complicated" characters, on some keyboards
> those aren't even indicated and you might need multifinger
> combinations to type them. If the key says "language format" I
> believe for the value we only have to define a separator. The strings
> between the separator will be "formats" and we'll not need curly
> braces to understand it (e.g. "de;fr" or "de+fr"). If you prefer, we
> could allow traling and leading spaces ("de + fr") for improved
> readability.
That is a very different idea and without knowing the supposed meaning
of this list of language codes i am not really sure what to think of
it.
The purpose of the format string is to allow documenting the locally
preferred form to display names - which is exactly what the name tag is
currently used for, just in a less transparent, less consistent and
more difficult to maintain and to interpret form.
--
Christoph Hormann
http://www.imagico.de/
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping language borders, tagging offical languages?
On Saturday 15 September 2018, Joseph Eisenberg wrote:
> * the choice of suggesting tagging the language information on either
>
> > the administrative boundary relations or the individual features
> > but not on any other feature with a meaning beyond the feature
> > itself was not arbitrary.
>
> Are you objecting to the idea of tagging places as well as
> boundaries? What about the protected area / aboriginal lands
> boundaries?
I don't think any tagging concept where the language format tag of a
feature other than an administrative boundary relation has a meaning
beyond said feature has a chance to be acutally broadly interpreted by
data users.
Once you start going down this road the interpretation will become very
complicated for the data user and completely intransparent for the
mapper and hence it would almost certainly fail to find acceptance.
> > * the choice of syntax for the language string is something that
> > can be discussed obviously. You can essentially use any characters
> > that are unlikely to occur in an actual format as structuring
> > elements. The dollar sign is a common symbol prefix here.
>
> OK, but is this necessary for it to work? Is a 3-letter ISO code
> sufficient?
> Would it be possible to put the language code in the key
> (language:=default) or is it better to stick to the value?
I am not quite sure what your suggestion is. You would need to
formulate a specific suggestion for me to determine if this would work.
In general in a format string you need a way to distinguish between
literal characters and characters indicating a symbol/variable. The
most common way to do that is to prefix symbols with a special
character. An alternative would be to enclose symbols in special
characters (like braces, e.g. language_format={de} - {fr}).
> > * the core of my proposal is not using the plain "name" tag any
> > more for anything other than legacy fallback if other data is
> > missing. Any proposal to separately tag the language of the name
> > tag ... is a very different idea.
>
> Functionally both ideas work the same, right?
No, most of the advantages of my tagging concept depend on not having an
aggregate name tag but tagging the individual names in different
languages (like name:en, name:fr) separately and defining the locally
preferred formatting independent of that.
--
Christoph Hormann
http://www.imagico.de/
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping language borders, tagging offical languages?
On Sunday 16 September 2018, Joseph Eisenberg wrote: > On Sun, Sep 16, 2018 at 1:23 AM Christoph Hormann wrote: > > > Are you objecting to the idea of tagging places as well as > > > boundaries? What about the protected area / aboriginal lands > > > boundaries? > > > > * I don't think any tagging concept where the language format tag > > of a feature other than an administrative boundary relation has a > > meaning beyond said feature has a chance to be acutally broadly > > interpreted by data users.* > > *boundary=administrative *may have up 9 levels in some places > *(admin_level 2 to 10*) > Do we need to limit the max admin_level that can be used for the > language tag? > If not, why would it be a problem to also search for boundaries of > aboriginal_lands in addition to 8 admin boundary levels? I am not really familiar with the legal status of aboriginal lands in various parts of the world and how use of the names differs betweeen the inside and the outside. I have a hard time imagining an aboriginal land with a distinct and homogeneous language use that is not also an administrative unit. If we could discuss this on a practical (and hopefully somewhat representative) example that would probably help. > > *language:default=* would have the code as the "value" in the > key=value pair > > Examples: > > *language:default=de* would be used on the admin_level=2 boundary for > Germany > *language:default=fr;nl *could be used on the administrative boundary > for Brussels > *language:default=zh;zh_pinyin* could be used in China, if the local > community wants to show the romanized name along with the Chinese > characters I am not sure what exactly this tag is supposed to mean. Is it just the format string i suggested indicating the locally preferred form of name display minus the actual form, i.e. reduced to a list of component names or is it something different? And how is the data user supposed to interpret this tag? Since you do not want to deprecate the name tag it is not clear to me if it is supposed to be interpreted in combination with the plain, possibly compund name tag or with the individual language name tags. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping language borders, tagging offical languages?
On Sunday 16 September 2018, Joseph Eisenberg wrote: > "you would need extensive external data to determine how to > actually display combinations of names (which obviously depends on > the languages and scripts involved)" > > Do you mean how to decide which name is displayed "first"? On the > left / on top etc? No, the order is simply a matter of deciding if your list is supposed to be an ordered list or not. I mean the form in which the different names are displayed. If you look at how the name tag is used in various parts of the world with combinations of different languages this varies a lot. I don't know how much of this is just arbitrary choices based on personal typesetting preferences and how much of this represents actual local cultural conventions but my intent was not to impose a culturally imperialistic corset on how names will be shown to all names world wide but allow mappers to document their local conventions. It is still up to the map designers how far they want to use that of course. The most common separating elements between different language names in name tags are '-' and '/' - usually enclosed by spaces. But that is obviously based on latin script dominance. Other scripts and to some extent also latin script languages have different conventions. If you have names in well distinguishable scripts a separator is often unnecessary and uncommon. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping language borders, tagging offical languages?
On Sunday 16 September 2018, Joseph Eisenberg wrote: > > *Would it be feasible for database users to query > boundary=aboriginal_lands along with the admin boundaries*? As said i can't really form an opinion on this without a real world example, the corresponding data and a suggestion how this should be interpreted together with the administrative boundaries. Of course you can somehow formulate a rule for that but i am not sure if this would make sense and be intuitive for the mapper. > It should be interpreted with the individual language name tags. > If the default language is zh;zh_pinyin (Chinese and romanized > Chinese), there should be a name:zh and name:zh_pinyin tag on each > feature within the boundary, in theory, and these two name tags > should be combined in an international map rendering. But then you would need extensive external data to determine how to actually display combinations of names (which obviously depends on the languages and scripts involved). Evidence in how the name tag is used for combining different names in different parts of the world shows that the local conventions on how to display different languages together varies quite strongly. Or in other words: It is very easy for data users to generate a list of languages from a format string if required but it is rather difficult if not impossible to generate an accurate and suitable format string for every combination of languages from just a list of languages. If this is just a question of typesetting rules that is the resposibility of the map designer obviously but i have the impression this is also a matter of local culture w.r.t. names and languages and that is something that can and should be mapped. -- 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 29 March 2019, Martin Koppenhoefer wrote: > > > * you should be aware that you can't uniquely define the shape of a > > two dimensional surface in three dimensions exclusively through the > > shape of its outline. You can do that in 2d (provided what you > > have has a defined outline) but not in 3d. That is simple > > mathematics. So you'd have to document what assumptions you make > > regarding the shape of the surface, otherwise the meaning of your > > proposal would be ill-defined. > > the general assumption for stairs is that all steps have the same > height and same "depth". That would not be a very sensible assumption since that would be impossible for any stairs where the upper and lower end are not equidistant across their whole length because then not all steps can have a constant depth. But my point was a different one. A polygon is by definition planar. If your modeling defines a non-planar outline (which it obviously does when you can have arbitrarily shaped upper and lower limits) then you need to make assumptions regarding how the shape derives from this outline. > While I agree with you that for 3d you need height information (the > area proposal has a suggestion for this), [...] You need this for any rendering of the stairs that visualizes the individual steps in some form (because their form defines a 3d geometry - even if you don't render it in 3d). > in the end, all areas can be represented as polygons [...] Well - that depends on how you define "area" obviously. A polygon is an attempt to describe a two dimensional planar entity through circular linestring representations of its edges. Even for 2d entities where this is possible (i.e. that are planar and have a well defined inside and outside) it is often not the most efficient way of representing them. -- 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. -constant width stairs
On Saturday 30 March 2019, Warin wrote: > > However where the stair width is large, say 100s of meters, picking > the centre becomes harder. That's an editor UI problem, not a data model problem. > Most renders pay no attention to the width > so the rendering is poor. That's because almost all rendering software lacks native support for ground unit operations so this is relatively complicated to implement. But designing data models to work around limitations of current software, in other words: Suggesting mappers to invest thousands of hours of work to spare software developers the need to learn what a projection scale factor is, that is not an approach i would recommend. But i am getting carried away... -- 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 29 March 2019, Warin wrote: > Hi, > > This one has been sitting for a long while! Still not certain about > some aspects of it. > > See what you make of it. > > https://wiki.openstreetmap.org/wiki/Proposed_features/Area-steps First agreement with Martin that you need to decide if you want to make a proposal for defining some polygon-like 3d surfaces in general of some sort or specifically to deal with steps only. In the latter case this should be clear from the tagging, i.e. something like type=steps_area and nothing generic. Two more general notes on the more fundamental underlying problem: * you should be aware that you can't uniquely define the shape of a two dimensional surface in three dimensions exclusively through the shape of its outline. You can do that in 2d (provided what you have has a defined outline) but not in 3d. That is simple mathematics. So you'd have to document what assumptions you make regarding the shape of the surface, otherwise the meaning of your proposal would be ill-defined. * tying yourself to the idea of polygons being the ideal way to map anything in OSM could prevent you from finding a both mapping and data use efficient way to document things. You should keep in mind that >90 percent of stairs that exist are simple constant width + strait step stairs that can perfectly accurately be mapped with a linear highway=steps and a width tag. If you approach the problem with how to extend this method in ways that are (a) optional and backwards compatible, (b) make use of the information already present in the linear way mapping and (c) that cover most of the other <10 percent of the cases without the idea that the solution *has to be in the form of a polygon variant* that would more likely yield an efficient solution. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping deforestation
On Monday 11 March 2019, Lorenzo Stucchi wrote: > [...] > > The idea was to map: bareland, artificial surface and forest. As a general principle in OSM we map positively what verifiably exists, not the lack of something. What you call "bareland" is at odds with that because it is essentially negatively defined (as land lacking vegetation). So in terms of choosing tags i would recommend you focus on positively characterizing what you observe. In areas of deforestation large areas of bare ground is typically a transient state that will overgrow again rather quickly (within months or a few years) with some form of vegetation, ob become regularly maintained by humans in some form (like farmland). We also do not have any established tagging for what you call "artificial surface" because artificial surfaces are created usually for specific purposes and we typically map them depending on this purpose. Whatever tagging concept you choose you should document your plans and discuss them with the local community beforehand to make sure your plans are compatible with the mapping and tagging habits of the local community. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping deforestation
On Monday 11 March 2019, Peter Elderson wrote: > Sorry, 2000. IIRC the saying is "two wrongs does not make a right". Original use of tags with the landcover key, that is mappers creating a new geometry with a landcover tag, is as follows (based on data from 2019-02-28): 72848 ways/relations (more of half of these created in organized mapping with tagging not being the free choice of the mapper) 1310 different users 494 of which have used the key exactly once (this, i.e. that about 1/3 to half of the genuine active users of a tag have only used it once is pretty standard but still this has to be kept in mind when contemplating such numbers) The reason why taginfo reports only the number of users who have last touched features with this key is not because this is particularly meaningful information but because this can be counted quite easily when processing a planet file (which is what taginfo does on a daily basis) while numbers on active users (i.e. who maps features with a tag or who adds a tag to features) can only be determined from the history. I can highly recommend Frederik's talk on the matter of OSM statistics which discusses this in detail: https://www.youtube.com/watch?v=Kx0KuvkbvfQ -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] motorcycle:scale
On Sunday 03 February 2019, Martin Koppenhoefer wrote: > > I noticed today that a wiki page for the rarely used key > > "motorcycle:scale" had been accidentally created as > > "Key:motorcycle:scale" > > thank you for this. You are known to put things polite, in all > honesty, there are good reasons to believe this was not > “accidentally” but yet another attempt to sneak mostly unused tags > without further discussion, notice or proposal procedure right into > the established tags section of the wiki. [...] Just to avoid misunderstandings - it is in principle completely all right to invent tags and document them on tag/key pages without creating a proposal. What is not a good idea is developing complete tagging systems this way without broader consultation. And what is in particular not advisable is creating a one dimensional classification systems based on combination of multiple largely subjective and non-verifiable criteria. This is the exact opposite of good tagging design. By the way: For keys taginfo provides information on the number of different users who have last edited features with this key - in this case 2: https://taginfo.openstreetmap.org/keys/motorcycle:scale This number could at least for key pages be used to show a warning that a certain key is not well established. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] motorcycle:scale
On Monday 04 February 2019, Martin Koppenhoefer wrote: > > But creating such a page or adding such tags to map features overview > pages is misleading when there is basically no or very few usage. > These tags should be documented as well, but the right place to do it > is in the proposal namespace. Disagree here - when you start using a new tag you should document it and you should do so on a normal tag/key page so someone looking for how to map the same thing will find it and see how it used so far and a data user stumbling across the tag will find it as well and know what it means. Proposals often cannot be easily found this way, there can be multiple contradicting proposals for the same tag, they are not indexed by taginfo etc. Proposals are about ideas how something could be tagged, not about documenting how something is tagged. The problem discussed here is different - it is about the creation of a complete tagging system on an abstract basis without the descriptions and definitions actually deriving from practical use and presenting this as if this was an established tagging idea with broad support. For this indeed a proposal is a more suitable place. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] motorcycle:scale
On Monday 04 February 2019, Frederik Ramm wrote: > > * invent keys - ok > > * document widely used/established keys that never went through a > proposal process - ok > > * invent keys and document them as if they were widely used or > established - questionable > > * the whole thing done by someone who has in the past unilaterally > documented their personal preferred tagging on the wiki, then made > mechanical edits to push it through, and when challenged in changeset > comments, cited the wiki pages they had edited themselves as an > authority - ... While i agree on this particular case your distinction can be easily misread to mean that mappers must not invent new keys or that they have to write a proposal for them. The reason i am emphasizing this is diversity. People in underrepresented parts of the world will much more often run across things for which no established tagging exists than we do - yet they have comparitively little chances to have such tag established or to bring through a proposal for them. And creating a additional hurdle for this by banning documentation of their tag from normal tag documentation (and therefore from showing up in taginfo, possibly also in editors etc.) is counterproductive. We already have way too many cases where mapping in parts of the world with a geography very different from that in Europe and North America people cargo cult a European geography - essentially drawing the map to create a look-alike of a European setting. Telling people they either have to use established European tagging or they have bury the documentation of their tags somewhere where no one can accidently find them is not helping with that. Note in the vast majority of cases we are talking about new tags, not new keys. But allowing documentation of new tags but not of new keys would be kind of weired of course. My suggestion: Create a new status value for the info box "not established" that is to be used whenever a tag has less than 500 uses and less than 20 active users. And highlight such tags with a prominent warning that this tag is a new invention not yet broadly accepted. There by the way is also another side to the whole subject - that is established tags with lots of uses for which there is only a proposal page. That is bad because a proposal page by definition describes an idea how a tag is supposed to be used while a tag page should describe how a tag is used. And even if at some point a wiki editor creates a tag page this is often with content copied from the proposal without checking if actual tag use is in line with that. Encouraging to create proposal pages instead of tag pages when inventing tags essentially encourages wishful thinking about the meaning of tags instead of actual documentation of the reality of use. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subtag for place=locality?
place=locality is currently used as a generic tag for anything with a name for which no established more precise tag exists. This kind of contradicts the idea of OSM which would normally suggest to invent a new tag then for the type of feature you have. Subtagging the generic tag to make it less generic would kind of take this to a whole new level. You could take this even further and suggest tagging everything in OSM something like 'feature=thing' and then differentiating only through 'thing=*'. Long story short - to better differentiate what is currently tagged place=locality the way to go is IMO to create more specific top level tags (or use existing ones like the mentioned "disused:/abandonded:"). -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
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
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
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] 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] 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] 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] 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] 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] 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] 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
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] 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 (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 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 (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
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 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] 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, 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] 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, 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] Feature Proposal -- RFC -- Landcover Cultivated
On Wednesday 10 April 2019, Mateusz Konieczny wrote: > [...] > > But in this case I am even more confused - with low quality images > how one is supposed to distinguish forest from orchards/plantations? Indeed. I don't see a lot of practical cases where you can reliably distinguish between cultivated and non-cultivated, between artificial and non-artificial but cannot make a more specific characterization according to the tagging system we have. For naturally unvegetated areas we currently have a somewhat incomplete set of established tags, mostly because the vast majority of mappers live in regions where these are rare. But the way to address this is to develop tags for specific features and not a general 'barren areas' tag that encompasses also several specific and well established tags we already have. -- 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] 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] Subtag for place=locality?
On Tuesday 16 April 2019, Mark Wagner wrote:
>
> There's a "place=locality" near me called "Seven Mile Airstrip".
> Now, that's an interesting choice of names for the place, because
> there's no evidence that it was ever used for aviation. The best
> guess I've seen for where the name came from is that it was intended
> as an auxiliary runway for Spokane Army Air Depot during World War
> II, and after construction was canceled, the name stuck around.
>
> What tag would you recommend for "thing people believe is the
> abandoned construction site for a runway that was never built"?
The crux about about abandoned:* is that it is usually only verifiable
as long as physical remains are present. I don't know this particular
situation but it looks like that is not the case here. The question
you need to ask yourself is what the name currently refers to and tag
accordingly. Is it the name of a section of a road ("drive east along
Seven Mile Airstrip"), the name of a neighborhood or parts of it ("i
live in Seven Mile Airstrip"), the name of some kind of common area
("lets have a barbecue tonight at Seven Mile Airstrip"), some patch of
wilderness ("i went hunting yesterday and shot a rabbit at Seven Mile
Airstrip"). If you can clearly give the named feature some kind of
classification of what it is that could also apply to other similar
places with different name elsewhere you should use or create a tag
indicating that. Only if that is not the case you might use the
generic place=locality - but only if it is actually a verifiably
locatable place and not just a name you have heard from your
grandfather to apply to a place around here somewhere but you can't
really specifiy what it refers to now.
If you look into the database you can find place=locality being used for
a lot of very different things most of which you could clearly classify
more precisely. A tag like place=locality will likely always exist in
OSM - even if this one is deprecated an alternative would be invented.
But it should be used as sparsely as possible to make the data as
meaningful as possible.
--
Christoph Hormann
http://www.imagico.de/
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] 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] [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, 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] 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] [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] 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] 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] 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] 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] 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] 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] 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] [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, 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, 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 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 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 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 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] 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] [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] [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] 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] 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] 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] 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
