Re: [Tagging] Tagging standards [moved from osmf-talk]
2022-10-23, sk, 22:31 Brian M. Sperlongano rašė:
> I agree that there is a set of "core" tags whose meaning is so widely
> understood
> and established that they are standard tags by usage and convention today. For
> the case of these "core" tags, I'm not sure what value we would add by
> labeling
> them "standard" and codifying their existing meaning.
As there have been incidents where widespread and basic tags have
been known and widely understood and still some inexperienced people
after several months of "practice" in OSM managed to push changes to
those with devastating effects still visible today it is still a very
good idea to clearly state such "standard" tags and "freeze" them.
There should also be clearly defined criterias:
1. how tags GET INTO such a standard "position" - for example
absolute count higher than N, or relative count of tag usage A versus
other variants of tagging the same class/attribute, timespan of usage
is more than N years
2. what are the mandatory reasons to CHANGE the meaning or replace
the tags with something new. My personal opinion this could be a
calculation of added value versus the change cost but there are
probably some other options ("voting" by random people as it is in
"wiki" should not be the option).
I strongly believe that freezing "main" tags for main landuse,
roads, waterways, buildings, places, MAIN amenities (classes used in
99% of map/gis products) would allow data consumers to spend less time
on running after changes, reading thousands of letters to identify
possible changes to important tags etc. Very few people care how
colour of a bench is tagged but all care how a lake is tagged.
--
Tomas
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fuzzy areas again: should we have them or not?
2020-12-21, pr, 17:47 Brian M. Sperlongano rašė: > The current data model works just fine for fuzzy areas: it requires a polygon > combined with tagging that indicates that the area is "fuzzy". Since the > current > data model allows both polygons and tags, fuzzy areas could be mapped just > fine from a technical standpoint. The question is not about their attributes (tags), but rather their geometry. All objects currently held in OSM are of large scale. Fuzzy areas are by definition objects of a much smaller scale. Having objects of different scale in the same layer (in the same database in OSM case) is not good (causes a lot of problems) from GIS perspective. So it is not good even if we do not add metaphysical properties like "verifiability". P.S. Third attempt: separate database? Or internal/technical separator field and filter on API level? With possibility to switch between the two in JOSM (and no possibility to edit both at the same time or reuse parts)? wink wink :-D ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=fell not rendered, alternatives?
2020-12-21, pr, 16:52 Anders Torger rašė: > But what to do if the things you want doesn't > really fit into what OSM currently is and strives to be... We are ALL OSM community. If somebody tells you that "I am OSM and only A is right" - do not believe them. YOU define what OSM is and where it is going to by DOING. The more I look at it, the more it seems that fragmentation is inevitable. Question is how much will remain "common". "Don't let the bastards grind you down" - U2 :-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=fell not rendered, alternatives?
2020-12-21, pr, 15:54 Anders Torger rašė: > A local renderer would be limited in use <...> Not necessarily ;-) 1. It could be a practical/visual proof of a "better way". 2. It could be a testing ground for finding solutions to some international (wider than OSM, say ICA) cartographic problems. 3. If enough local communities create cartographic data schemas, they could technically align them (tagging-cartographic maillist?) and then data consumers would have to adopt to that as well. 4. I'm not aware of the outdoors map specifics in Sweden, but at least here OSM maps update much faster and also include specific/thematic information for tourism, cayaking, craftbeer, history and all other good things which official sources do not have. And having all of that in one database (rather than an overlay) has some important benefits. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] natural=fell not rendered, alternatives?
2020-12-21, pr, 14:42 Anders Torger rašė: > I personally want to see that the community work for a more defined > mapping baseline with OSM-Carto as a strong reference, used as a > motivational tool for crowd-sourcing, and as it is with the current > provider landscape -- also work as an end product. It does in parts > already, and I want to see more of that. I also got a sense of urgency, > map density in OSM has improved a lot, data sources that a mapper has > access too has also improved a lot since OSM started, so mappers can > today map much more than they could before and are more motivated to do > so, at least in some places in the world. I want the OSM technical > platform to be ready for that. In OSM for natural reasons cartographers are a small minority comparing to majority of coders. Therefore cartographic goals do not get through a "coder filter" (it is more important for majority to have clean code than to have clean map). You might try, but in my experience the only way is to: * have a more cartographic agreement with local community (it is easier in small scale, as you can meet in person, show good examples and thus prove the value of cartography) * have your own country renderer (you can start with VPS for ~100EUR a year and go up as your usage grows). * have your own country editor with your regional tagging schema (I will publish instructions on how to do that in a month or two) * do most of the work yourself (or with a small group of cartography oriented people) at least initially as resistance will be there anyway until you prove/show results You will have cartographic maps and will not have to waste time agreeing on cartographic nuances with people who do not understand cartography. You will simply agree about them LOCALLY and use them (OSM has a rule of "free tagging"). P.S. Frederik is right about fuzzy features, even in cartographic perspective they do not belong in the same bucket as current OSM features. I think you should have a separate database for those. It is not hard to implement that as amount of data/changes is much lower. They later end up in the same database in similar GIS tables as main OSM data therefore are seamless to use in final products. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds
2020-12-21, pr, 11:02 Volker Schmidt rašė: > Mass deprecations are counter-productive in general and independently of > whether they the new tagging is better in some way.. +1 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds
2020-12-21, pr, 01:10 Clifford Snow rašė: > Please refrain from calling out others as outlined in the Etiquette > Guidelines [1] Can you be more specific? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reservoirs, lakes, and ponds
2020-12-20, sk, 17:59 Paul Allen rašė: > Too late, at least for iD. Its authors have already decided to deprecate > landuse=reservoir. All this proposal does is document the fact. Strange sequence/logic tho: 1. iD brakes the rules, does something contrary to what OpenStreetMap/mappers do, 2. instead of fixing the offender - iD, Brian decides to bend the rules... ignoring the cartographic advantages of landuse=reservoir and impossibility to achieve "full rule of natural=water" in any near future as there are a lot of other tags to be massacred, not only landuse=reservoir. waterway=riverbank - 255K water=riverbank - 1K <- this even with iD once again lying about it being deprecated... I hope this proposal will be ignored as the initial one ten years ago was. 20-30 people voting is nothing when we talk about tag with almost 400K and much longer usage. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-17, kt, 18:20 Joseph Eisenberg rašė: > That's not accurate, Tomas. Why? Mateusz without the end of discussion started, well continued editing the wiki (I had to correct some of his misinterpretations which have been discussed here), he also made some attempts in JOSM trac, these are the things I follow, but I do now follow Mateusz personally, so gods know where else he is buldozzing. This is only pushing towards the splitting of tagging standards even further. We will introduce our approved tagging schemas/tools in Lithuania, somebody will follow (some probably have already done so) and what will we have then? I guess a wonderland for global data consumers. We probably need per country tagging lists ;-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rapids (whitewater) on rivers
2020-12-17, kt, 00:02 ael via Tagging rašė: > This is slightly off-topic in that I am picking up on the > hazard tag rather than rapids. I see no objection to adding hazard=rapids > although that might be redundant unless there exist rapids that are > not hazardous. I suppose shallow rapids might qualify. Note that rapid does not necessarily have to be interpreted as hazard. If prominent on the ground it can be one of orienting points (with bridges, settlements, intakes etc.) - to cover distance covered/remaining. We have a lot of "small rapids" which can be easily passed with no risk even with babies and they're still marked for orienting purposes. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
And while we're discussing here, Mateusz is already on a rampage to change wiki pages, write patches etc. Thus buldozzing his opinion, ignoring others. Showing "community building" behaviour. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-16, tr, 20:30 Kevin Kenny rašė: >> https://upes.openmap.lt/#17/56.296411/22.330154 > Looks good, I think... but what is the tagging? waterway=rapid At the time of usage it was deprecated (and plural), but I know what that means and after each discussion on tagging list I'm less and less inclined to propose/discuss anything here and evenmore editing the wiki. My take is that cayaking info is added to be used for specific purposes (well, cayaking) by specific people (cayaking enthusiasts, cayaking service providers and tourists) so we know the practical usage, we know cartographic requirements for data, look for suitable tags in other places and use them, if there are none or they do not fit the purpose - we add required tags. Important thing is that we can distinguish each feature and if some more suitable tagging schema emerges - we can always re-tag everything in a minute (and change software in a day). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-16, tr, 20:03 Kevin Kenny rašė: > Many smaller reservoirs have artificially hardened shorelines completely > surrounding them, which could be why you thought that the symbology > distinguishes 'lake' from 'reservoir.' This might be correct. I guess it depends on direction you look at it: what is exception from the reservoir rule - hard shoreline or non hard. I was thinking of the ways to map fuzzy shore in OSM and had the same idea to tag fuzzy shoreline as a line - this would be the same way as in your example but would need to de-emphasize rather than emphasize the shoreline. And I'm sure I've seen a legend with blackish border for reservoir, but do not remember if that was USGS or NATO map (reservoirs have some distinct properties worth depicting on some specific maps)... And I remember talking about lake/reservoir black border symbolisation with one of the leading cartography experts in Lithuania. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-16, tr, 19:44 Kevin Kenny rašė: > With respect to water, another concern of mine is that our tagging schema > does not > offer any way to tag that there are rapids in a river without knowing how to > grade the > difficulty of a canoe or kayak run. Why? Cayaking info is pretty rare - opposite of lake/reservoir data. Therefore it's fine to map what you need only: https://upes.openmap.lt/#17/56.296411/22.330154 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-16, tr, 18:58 Ture Pålsson via Tagging rašė: > Could you elaborate a bit on what cartographic features on that map are > possible or impossible with the different reservoir tagging schemes? Symbolisation (colour), selection (different classes for different scales). In other maps reservoirs (US?) could have black border. GIS analysis is another beast where these classes are important as different. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-16, tr, 18:04 Mateusz Konieczny via Tagging rašė: > Then I can you show some map style that do it differently and > render all types of water areas in the same way (some > render also labels in the same way, with exception > for linear features) BTW. It is another advantage of landuse=reservoir schema. It forces people creating map to understand that there ARE different classes of water. Then they have to understand what those classes are (and why) and choose which are appropriate in their particular products. If you have an umbrella tag like natural=water most will simply go with such simple where condition and therefore miss some very important things (and create low quality maps, and will not learn important lessons). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-16, tr, 18:04 Mateusz Konieczny via Tagging rašė: > Then I can you show some map style that do it differently and > render all types of water areas in the same way (some > render also labels in the same way, with exception > for linear features) > https://www.openstreetmap.org/#map=14/54.3643/18.7150 > https://www.openstreetmap.org/#map=14/54.3666/18.7138=C > https://www.openstreetmap.org/#map=14/54.3666/18.7138=T > https://www.openstreetmap.org/#map=14/54.3666/18.7138=H Why is there no label for waterway polygon? What about maps made according to Cartographic conventions? You know, something on the lines of: https://map.geo.admin.ch Would it be possible to make maps of such quality writing general queries like natural=water? A lot of Cartographic papers are open. Look at those mentioning VGI or OSM directly and check what cartographers very diplomatically say about OSM maps/cartography (not data). Why is that? Could it be that there is simply too much resistance to push something more advanced into OSM? >> Best system is to use codes, not names for keys/values, but that is a >> totally different "saga". > Feel free to propose this one. From my perspective there is a big problem with making complex changes/decisions (requiring a lot of specific/thematic knowledge/experience) as there is no way to value "votes" of people with different experience differently. If it is not valued differently then the result you get is an average. What is an average of 1, 1, 1, 2, 2, 50? Why would 50 want to be involved in something where result will be 10 and you would have to fight for each action? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-16, tr, 17:19 Brian M. Sperlongano rašė: > The statistics reflect all areas, regardless of which editors were used to > create them. > I stand by them, as numbers do not lie. Have you heard of the saying "correlation is not causation"? You have to understand where numbers come from and why in order to use them. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-16, tr, 17:04 Mateusz Konieczny via Tagging rašė: > I agree that it is useful only for primitive rendering of water areas > (that possibly filters water areas by area but does not distinguish > between lakes and rivers). It may be worth mentioning. > > But it is also the most typical and common way of rendering things. How do you decide that it is most typical and common way of rendering things? ALL maps I created or seen in GIS/Cartography world, be it online or printed, interpret water classes differently, especially basins/riverbanks... And it will be even more important moving to vector tiles. > This is a double edged sword, it also means that mapper unsure > whatever something is natural or man made (common in case > of mapping based on aerial images, sometimes even in > case of survey) is unable to mark a water area. But that is a point, mapper should find out if we want to have higher quality data. There is usually some source available you can use. You can always add fixme, if you're unsure. And for the case of pond it IS possible to distinguish it from reservoir/lake straight away. > And distinguishing natural vs man made is still possible > with water tag anyway. 99% water objects mapped with iD I've seen are water=pond... > (similarly like I have not mentioned that both natural > and landuse are quite counterintuitive key names here) Best system is to use codes, not names for keys/values, but that is a totally different "saga". ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
Brian, you're using statistics which DO NOT represent mappers preferences. If you would use only JOSM created objects - then it would be close to mappers preferences (as JOSM allows mappers to choose). But you use iD created/adjusted objects and as it does not allow showing your preference (drilling down into tags is only a theoretical possibility) and even pushes you to overwrite other peoples preferences you have to exclude iD tainted objects if you're trying to get "community preference" from statistics. Therefore I would suggest starting with the core - arguments advantages/disadvantages of both schemas. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-16, tr, 16:01 Mateusz Konieczny rašė:
> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
> (just added)
Thank you. Maybe it is better to discuss here before adding to wiki?
My arguments on the points you've added:
1. Regarding benefit of having a combining level/tag natural=water.
If today you would query all data with natural=water - you will get
not only lakes and reservoirs grouped, but also riverbank polygons
(totally different beast) and micro elements like water=pond. This
could only be partly useful in the largest scale maps and only if you
make very simple maps and for some reason use the same symbolisation
for such different water classes. For example ponds usually have less
complex and less prominent symbolisation because of their size and
importance. Riverbanks would not need polygon labelling, but rather
use river (central) line for label placement. Most of GIS/Cartography
work goes in middle/small scales and it will be impossible to use only
natural=water there, you would have to add "and water not in
('riverbank', 'pond', ...)". This erodes the benefit of "one tag" and
makes it of the same complexity from coding perspective as original
water scheme.
2. Very important disadvantage of water=reservoir from
cartographic/gis perspective: it allows mappers to NOT differentiate
between natural lakes and man made reservoirs. If first point
describes how different classes are USED, this second point is about
how these classes are CAPTURED.
Did I miss anything?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
> I get that you consider benefits of natural=water water=* schema > as unimportant Can you LIST the benefits? As you see them TODAY. So that we could evaluate/compare? (Not point to proposal on wiki, as largest part of it never materialised) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
> If you believe that your argument in favor of tagging reservoirs as landuse is > strong, then you should have no objection to placing this question up for a > community vote, and allowing the community the freedom to decide. Brian, landuse=reservoir is the ORIGINAL and ACTIVE schema. Why should anybody propose the vote for it? I do not like voting on wiki because it is clearly a flawed process (as discusses a number of times), what do 20 wiki participants/people mean against the actual mappers? We could end up in the same situation as with original water=reservoir proposal where somebody with barely few months of participation in OSM and no knowledge of GIS/Carto makes/influences the decision/proposal... And what is a problem of listing benefits of water=reservoir schema? If there are none, then the only logical decision is to deprecate water=reservoir, because it would make it worse of the two. Shouldn't we get ARGUMENTS before we go to any kind of voting/decision? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-16, tr, 01:32 Brian M. Sperlongano rašė: > The iD editor preset appears to use water=reservoir while the JOSM > preset appears to use landuse=reservoir. Not entirely correct. * JOSM gives freedom to mappers and supports BOTH. * iD forces to use water=reservoir and evenmore pushes users to change tagging by disguise of "upgrade" - therefore even mappers who do not understand/know the difference are inclined to change the tagging. <- this is the reason for current stats My understanding is that given landuse=reservoir is the original water schema, the new one should show some benefits to replace the original one? Or we do not care about consistency and simply go on with replacing very prominent schemas for no good reason? My take is that: * landuse=reservoir is better compared to natural=water+water=x because it pushes mappers to make distinction for these GIS/Cartographically very different classes of water. Therefore if landuse=reservoir is deprecated tagging will be worse. What are the benefits of water=reservoir? Given that full scope of proposal to put all water classes under natural=water (the purpose which is disadvantageous from GIS/Cartography perspective) have failed and we're now only talking about two classes of water (natural and man made), and classes which are very different and therefore should not be merged. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-13, sk, 20:41 Mateusz Konieczny via Tagging rašė: > Following outcome of approved proposal that you dislike > is not indicator of not following > standard IT processes of product development. Following some wiki page (which states that landuse=reservoir is not deprecated) written by one person and voted by few rather than de facto situation in other editors and database is huge problem with analysis. In case of iD it is even worse - it shows coders of iD did not want to give a tool, but rather to make influence which they continue to do quite openly, especially with a tactic of "upgrade tags". Compare that to JOSM - which is democratic, follows OSM principle of freedom and lets us - mappers - choose. Both schemas are mostly identical in what classes of object can be mapped. 1. water=reservoir benefit could have been on coding side: having natural=water as an "umbrella" tag but it did not work out that way (so I do not know what is a perceived advantage now?) 2. landuse=reservoir benefit is GIS/Cartographic: we must indicate if it is a natural or man made waterbody. Now you decide which is more important to openstreetMAP. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-13, sk, 20:09 Mateusz Konieczny via Tagging rašė: > 2020-12-13, sk, 19:18 Mateusz Konieczny via Tagging rašė: > Mateusz, can you point out which of my claims is a lie? > > "iD coders decided to skip standard IT processes of product development > (or were not familiar with the basics of IT)" Let's go back in time. It is 2012. iD developers are to add water tagging schema to their newly baked editor. The candidates are IN 2012: 1. landuse=reservoir - the only schema in activu use, widely used, 200K objects tagged, documentation written, tutorials written. 2. water=reservoir - unused (5K? 10K?). iD developers decision: go with option 2. I do not see how such decision could be counted as "IT-wise sound"? (my suspicion is that the reason was iD's tag layout being tag+subtag and there water=reservoir was better suitable, but this is just my speculation, if true that would be one more proof of lack of IT experience) > > "coders of iD decided to lie to the users that landuse=reservoir is > deprecated which it never was" > > It is deprecated by 2011 proposal, see > https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details#Deprecation Please read everything, not only the part you're interested. Zverik agreed that it is NOT deprecated. And it was agreed in many many other discussions that landuse=reservoir was NEVER deprecated. > usage/requirements must lead technical decisions. That is IT BASICS. > > It was not an unused schema and it was proposed, approved and used before iD > started using it and later aggressively promoting it. 2012: landuse=reservoir - 200K, water=reservoir - 5K? 10K? Should we continue to argue in the dungeons of history without thinking about the future? The problem is that it dragged for almost 10 years. Now ANY decision will be bad. That is why decision is always postponed, but time will not change anything. The hole is till there, there are no rules/process to circumvent that. So the situation can repeat again. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-13, sk, 18:58 Brian M. Sperlongano rašė: > Let's please assume good faith and be respectful while we discuss > differences of opinion with an open mind - we are all here for the > same reason - working together to create the best possible map for the world. I do agree that sometimes I get carried away, sorry I will try to reduce that. At the same time I ask to actually discuss the reasons why this saga happened and ways to reduce the possibility of such harmful duplications happening again. Bulldozing one opinion and ignoring the other is not a good solution. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-13, sk, 19:18 Mateusz Konieczny via Tagging rašė: > New/duplicate schema with water=reservoir only launched because iD > coders decided to skip standard IT processes of product development > (or were not familiar with the basics of IT) and simply went for what > they personally liked, not what was better > > This is 100% untrue, and you insult people. Stop making such things. > > For start, iD authors (also ones that made decisions about tagging > presets that I consider to be mistakes and going against consensus) > had no problem with basics of IT and IT processes of product development. > > water=reservoir was launched (created) in 2011 > see https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details > iD started in 2012 ( https://wiki.openstreetmap.org/wiki/ID ) Mateusz, can you point out which of my claims is a lie? I didn't say iD invented duplicate schema, I said that schema was lying dead until iD decided to introduce it as the only way to tag water, introduction "launched" new water schema adding any considerable usage (as it was the only option for iD mappers). Introducing duplicate and unused schema (especially as the only option) is not a good IT decision, basic analysis should have shown that. But in case of id it was technology leading functionality and thus leading users when in IT it must be the other way round - usage/requirements must lead technical decisions. That is IT BASICS. Lack of such understanding is the reason why I claim iD developers lacked basic IT knowledge. > , and introduced > water=reservoir as the only way to tag, all this at the time when > water=reservoir usage was close to zero! > > See https://taginfo.openstreetmap.org/tags/water=reservoir#chronology > > Usage in January 2019 was about 200 000 already. > > "water=reservoir usage was close to zero" is untrue Key word "introduced" so it is 2012, not 2019. water=reservoir usage in 2012 is close to zero. > It is deprecated by 2011 proposal, see > https://wiki.openstreetmap.org/wiki/Proposed_features/Water_details#Deprecation The author of this proposal agreed that standard water schema is NOT deprecated. And a few people voting in wiki cannot deprecate a tag. Only people actually mapping can do that. > BTW, you are AGAIN spreading false statements and claim that iD > invented water=reservoir. Please stop doing this. Do not copy/paste my words in random order and you will not get such claims from me :-) Anyways, there is no way I will be able to teach IT things people who do not want to learn. Let's not rewrite the history of this saga and lets move forward instead of repeating the same discussion again and again. Let's do what is possible so that this does not happen again: * When tagging schema CAN be changed and when it CAN NOT? * What ADVANTAGES are required to allow deprecating current schema? -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
But prudent way would probably be to come with some rules on change of tagging schema. Like: * When tagging schema is too widespread to be protected against changes * What benefits should new schema add in order to deprecate existing schema Because otherwise this plague of deprecating existing widespread schemas (water is not the only impacted area here) in order to bring some dubious "benefits" will continue. Some people simply do not have experience and do not understand what is the value of stability and what are the actual costs of changing something which is already widespread (for this I like to give an example of highway tag which is was correct when it was created but is incorrect now, but we do not change it for the same reason of stability and total cost). P.S. Stability does not necessarily prohibit freedom of tagging. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The saga of landuse=reservoir vs water=reservoir
2020-12-13, sk, 16:13 Brian M. Sperlongano rašė: > 2019 was a turning point, and over the last two years, landuse=reservoir has > been on a steady decline, while water=reservoir continued its rapid growth. New/duplicate schema with water=reservoir only launched because iD coders decided to skip standard IT processes of product development (or were not familiar with the basics of IT) and simply went for what they personally liked, not what was better, and introduced water=reservoir as the only way to tag, all this at the time when water=reservoir usage was close to zero! And the only reason for change of stat starting 2019 is because coders of iD decided to lie to the users that landuse=reservoir is deprecated which it never was and started replacing landuse=reservoir under their highly controversial disguise of "upgrade tags". So the change of statistics is not the preference of mappers but preference of some nerds. > Is it time to more directly recommend that mappers favor natural=water + > water=reservoir > *instead of* rather than *in addition to* landuse=reservoir? I would propose to deprecate water=reservoir and even more - add guards so that such pointless/nerdy duplicate standards would not be introduced in the future. Note that one of the main nerdy points of this schema was to have a possibility to write sql easier (somebody has problems with "and/or") and this would also require riverbanks to fall into this new water schema. And riverbank clearly does not fall into that even with iD lying about it too. Therefore the only point has failed and this stupidity is spreading havoc in tagging of such prominent water features for more than 10 years now. P.S. There is quite an easy solution to have a separate iD instance for beginners with correct tagging presets loaded. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
2020-11-08, sk, 19:54 Joseph Eisenberg rašė: > The reason is that at mid zoom levels there is far too much data > in the database for it all to be made available in a vector tile > format so that the map is fully customizable. Unless we will do a real generalisation which would mean we will start doing cartography! Which is where all this thread started ;-) As for open source software stack. The only feature which is missing is to cache layers separately (where "layer" is buildings, water, landuse, places, could be two different versions of say landuse etc.) and then combine them dynamically to final vector tile pbf on the fly depending on the request. With postgis introducing vector tile generation on the database side I think we will not have to wait long for a lot of vector tile servers to pop-up. Client side: mapbox has done almost nothing with regards to cartography in the last two years (and is still lacking support for non abstract patterns, so things like wetlands look like crap), but harpgl is gaining and you can always use openlayers which would be not as sexy (fast), but for example you would have high quality text (compared to webgl text). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
2020-11-08, sk, 09:46 Mateusz Konieczny via Tagging rašė: > (and it is from person who put a lot of effort into tagging improvements, > wikifiddling, > deprecating some unwanted values, deduplication and validator-related work > and has > some experience from data consumer side) That is a lie, as you're supporter of harmful duplication of water schema :-D ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
2020-11-08, sk, 12:31 Anders Torger rašė: > To me it seems like an odd "political" design decision to have a > separate database though. Why just not arrange the database in layers, > and this could be a separate layer? From a technical perspective I > suppose it wouldn't have to be layers as such, one layer could in > actuality be a tag filter. It must be separate enough to: * not allow reusing objects from "main" database * to have different description on what is allowed in it (for example allowing objects borders of which cannot be precisely defined etc.) In general it is an advantage that the main database does not have layers. In "standard GIS" layers separate data thus we can get bus stops in the lake or on the building, road going into the lake etc. In OSM it is much easier to spot such problems (and fix them) because it is only one layer. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
2020-11-08, sk, 00:00 Anders Torger rašė: > Maybe this is self-evident to anyone that knows more about this than I > do, but I have to ask, are you saying that when we have to implement > generalization to be able to serve vector tiles, it's also natural to > include generalization of names? Meaning that we could see more names > than we do now when we zoom out, so perhaps rural areas don't get the > empty-map-syndrome? That would be awesome. Names do not take too much space in vector tile. I was talking about larger objects like landcover, water, buildings. > In addition I still want some method to name features in the landscape > though, that supports automatic generalization. I thought named areas > was an elegant way to do this, but it seems some have very strong > opinions against it. If we're talking about fuzzy features (which do not have specific boundaries) like mountain ranges, bays, straits etc. the problem is that just a point is not enough, text must have direction, sometimes even curvature to follow the geometry of the object ant thus "connect" the label with the object in our consciousness. Additionally, for some objects, say bays, we need totally different set of labels for different zooms and that can only be calculated if we have a polygon (check water labels and how they change https://topo.openmap.lt/#t/13/54.33547/24.36494/0/0/ starting with zoom 16 there is actually a lot of labels placed in different places of the waterbody). But placing polygons for fuzzy objects have problems: * borders are not verifiable on the ground (as there is actually no border - object is "fuzzy") * imprecisely drawn boundaries of such objects look bad in the editor, intersect with other objects and this kind of pushes mappers to simply use boundaries of existing features (like coastlines) which makes those object waay too precise for fuzzy objects. My personal opinion is that such objects could be moved to a separate database specific to fuzzy objects. That database should not have ANY connection to the main database so that mappers would not be able to reuse geometries of the main database. Thus license would be the same, toolchain would be the same, data could later be used alongside the data from the "main" database. Everyone should be happy, both arguments (Christophs and Frederiks) against such objects would be satisfied? -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
One more thing to consider: generalisation is one of the most important things for cartography, but it is also extremely important for vector tiles. 2-3 years ago we've played with government data and it produced huge (up to 4MB) vector tiles (pbf) for middle scales (zoom 8-12). Browsers (especially mobile ones) were struggling with that amount of data. Even moderate generalisation reduced the amount of data to 0,5M. It is something which is currently brushed under the carpet as using raster will never produce a tile that large. What I'm saying here is that generalisation (the real one, not DP) will have to be done anyways as OSM community is starting to see the disadvantages of legacy raster maps and is getting used to the idea of vector maps (for the client, not between servers). 2020-11-07, št, 21:23 Anders Torger rašė: > (I had to run it in Chrome, it didn't render properly in my Firefox, but > this vector stuff is new tech and Linux Firefox seems to have some > issues with that.) Strange. Firefox on linux is my primary browser, it is the way I always use/test *.openmap.lt... ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
2020-11-07, št, 14:37 Jeremy Harris rašė: > Alternatively, could the rendering job be done by the client needing the > out-of-date tile, and resubmitted to the server? As Mateusz has pointed out, this has already existed, but one of the reasons it was discontinued (along with the lack of interest) was that it meant you're rendering and rerendering a lot of tiles which nobody needs. Renderer must be connected to actual usage of the map. Another thing with rerendering (and it actually is a problem for both client and server rendering) is segmentation. When doing generalisation a lot of things aggregate, so even when nothing changes on your particular square (data-wise), result could change because of changes in neighbouring squares. There are a lot of segmentation strategies to be used depending on types of objects being worked on (and types of generalisation operations being performed on them), but it is not as simple as current usage with osm2pgsql generating dirty tile list. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
2020-11-07, št, 13:24 Anders Torger rašė: > However, and this is a big however, I think that the face of > openstreetmap really need to be a cartographic sound map. During personal meetings as well as during different presentations in conferences I've been showing people two maps (one was google, another one was swiss topo https://map.geo.admin.ch). Google is one of the worst (from cartographic perspective) and Swiss topo is one of the best (Generalisation book of Swiss cartographers is like a magic book). And surprisingly (or not) a lot of people still prefer google style maps (at least for on-screen maps where you can zoom). In this year's SOTM Baltic the audience was split roughly 50/50 between google/swiss topo. So it is not clear which is better even if we do not think about technical difficulties. > And howcome did I not even know about this cartographic project of yours? Because it only covers Lithuania, because it is done as part of Lithuanian fellowship of cartographers, not international. > I assume that many, perhaps most, casual mappers use the web editor. Most edits are done with the main OSM editor which is - JOSM. > I'm > really impressed with the web editor, it's great and is mostly > user-friendly, And is very prone to damage good data. We (in Lithuania) encourage everybody to switch away from iD as soon as possible. Also note that cartographic style needs even more stuff, not only hardware and ideas (most generalisation tasks are not solved because algorithms are not designed/crystalised, coding is the least of the problems). In order to do good cartography you would have to agree on a much stricter use of tags and sometimes push some things into tagging which a lot of participants of this mailing list could disagree - for example road network hierarchy. Fuzzy features (like continents, mountain ranges, bays etc. should probably be moved to a separate database). -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Basic cartography features missing, why?
2020-11-07, št, 00:41 Anders Torger rašė: > However, how important is it that update of the map is immediate for every > database update? <...> OSM-Carto is a style whose purpose is to visualise OSM data to MAPPERS, do it quickly (fast feedback is essential). OSM-Carto also has a requirement to be easily deployable by almost anybody on any hardware. This means that pre-processing of data is impossible as per requirements (not a design decision). And without pre-processing it is impossible to have a cartographically sound map. So even while the OSM-Carto team is doing a terrific job and they do have people with good cartographic knowledge (like Christopher), but OSM-Carto does not have such a purpose - cartography. We're playing around with a small project striving to comply with cartographic rules - topo.openmap.lt - some data is updated daily, generalisation is done weekly. But you already get generalised roads, buildings, smart lines for waterbody labels as well as text size and letter spacing. This should get cartographic simplification for waterways this coming spring (not DP or VW, but Wang-Müller). So this can be done, but OSM-Carto is not the place to do it. Therefore if you want to have a cartographically sound map - you will need a separate project - separate rendering and stuff. You're totally right - for general (not mapper) use, minutely update is less important than cartographically correct representation. And also not everything has to be generalised, some parts could be updated very fast, some could be updated weekly or even monthly. Segmentation of data could also get more attention (re-calculating only the parts which need re-creation). Such tasks could even push forward topics which are currently the target of generalisation and multiple representation group of International cartographic association - I really think OpenStreetMap has people and capabilities to have a say there. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Riverbanks
2020-07-21, an, 15:17 Mateusz Konieczny via Tagging rašė: > Because despite claims mentioned above - there are also people preferring the > second schema, > it is not case of "iD developers vs community" like it is/was with some case. Situation when there are no barriers to changing widely used tags is very dangerous. What would happen if somebody would see one of numerous discussions about how highway tag is "incorrect" (as it could signify things which are not highways) and propose a new schema with totally different tags, and then iD goes out of fashion, somebody writes a new editor ChakaLakaLekker, makes the "new" road/way schema the default/only one available and in some time starts deprecating/removing highway tags. Would that be OK? If not, why was it allowed with water? P.S. Christophs thoughts are also right on spot, but it requires going even further - to cartography. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Riverbanks
2020-07-21, an, 15:00 Mateusz Konieczny via Tagging rašė: >> It is totally NERDY. > What you mean by that? There are two very different things: * IT * coding IT considers wider/higher-level things like stability, quality of the final product, documentation, usability etc. etc. IT expertise is gained by years of doing work on IT (coding is NOT IT expertise). Only coders/nerds are interested in things like "making sql slightly easier to write in some cases". Such motivation would be totally insufficient for ANYBODY with at least a little bit of IT experience to cause change of widely used thing (in this case water tagging schema). Such change would be considered stupid by anybody with IT experience. Only nerds care about where clauses having one line or two lines without thinking about the wider picture: data consumers, documentation, videos - stuff which is already produced, stuff which in some cases cannot be changed (like printed books) or costs a lot to be changed. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Riverbanks
2020-07-21, an 13:15, dktue rašė: > > So why can't the wiki state: "If you tag, then please do so using > waterway=riverbank" (as this is preferred by the *community*)? > There is no way to calculate the "opinnion" of the community and authoritarian/dictator attitude of iD coders and lack of action ramped up usage of nerdy schema close to original OSM one. And there is nobody bold to solve this, as there is no governing body/expert group. Local communities can do it. In Lithuania nerdy scheme is prohibited in favour of clean and consistent data. > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Riverbanks
2020-07-21, an, 11:20 dktue rašė: > Why do we need both variants and why don't we just say that > waterway=riverbank is preferred? There is an original OpenStreetMap water schema with lakes as natural=water, reservoirs as landuse=reservoir, riverbanks as waterway=riverbank etc. It is a perfectly working schema. At some point there was a new schema proposed with a totally nerdy motivation "to make some sql's simpler". That new schema has no advantage in cartography, GIS or IT sense. It is totally NERDY. This nerdy scheme was ignored in the beginning but then came the iD which took a totally non-analytical and authoritarian attitude and not only chose to support nerdy water schema, but even decided to support ONLY it. And in recent year iD coders went even further and started lying to its users that original OpenStreetMap water schema is "deprecated' even when it never was. So this is the reason why we have two schemas. It is very unfortunate that there is no way to prohibit such nonsense nerdy schemas into OpenStreetMap :-( -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM
> Very well put! If I understand correctly, to do this without heavy > pre-processing, > the information would have to be in the tags? > Would it have to be in the tags of every individual way, or would a tag on > an encompassing area (e.g. landuse=residential) be sufficient? Correct. Information would have to be on individual ways, because say two identical parallel ways close to one another should have to be reduced to one way. Even more: road network pruning is scale dependant, so additional information could be multiplied by the number of scales required. Note: additional information on ways would have to be adjusted even if the way itself does not change but information in surroundings change. For example forest path can be placed on a map (in a middle scale) but later removed after a parallel road is built alongside the path (say 50m away from the path even without touching/influencing the path itself). Therefore such tagging would go against OSM conventions. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM
2020-05-23, št, 04:51 Jarek Piórkowski rašė: > See also: not rendering roads or hamlets in very sparsely populated > areas because we have one map style which needs to accommodate central > European densities. OSM-Carto is a very well done DATA VISUALISATION. It is not a cartography. What you're asking cannot be done with only tagging as you will have ways which look exactly the same but will have to be removed in one place and will remain in the map in another place. What you're asking is accomplished in CARTOGRAPHY by "road network pruning". It checks density/class of roads and removes minor ones at the places of high density. It is one of cartographic generalisation functions. All important generalisation functions take additional heavy pre-processing and that is probably a reason why OpenStreetMap does not have any Cartography projects yet. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] landuse meadow getting the right description emphases
2020-03-15, sk, 08:53 Warin rašė: > There is no real 'force' on a mapper to do anything. If a mapper chooses not > to use the subtags then they don't have to. landuse=meadow was mention together with natural=grassland etc. If it is only about subtags meadow=* - I'm fine with that. > Similar can be said of many sub tags. If mappers want to map it then give > them a way to do so in a logical manner. Sure. That is why I commented. Amalgamating landuse for map rendering is not a trivial task. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] landuse meadow getting the right description emphases
Why would you want to "force" using more than one class for meadows when absolute majority of maps will not need more that one class? -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?
2020-01-28, an, 20:15 Jmapb rašė: > Thanks for the background. Looks like Richard Fairhurst already reverted the > "shared foot/bicycle must be path" assertion on the cycleway=* page. J Yet for ten years or even more the logic was that if the same way is designated for both pedestrians and cyclists, it cannot be tagged with highway=footway - as it is for cyclists as well, it cannot be tagged with highway=cycleway because it is for pedestrians as well, so such shared ways for this long period were tagged as highway=path+bicycle=designated+foot=designated. This has also been the preset in the main OSM editor - JOSM. This is in documentation and maps for ten or more years. Are there any reasons why this must change now? Any benefits? -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Strange tags
2019-09-30, pr, 10:35 Martin Koppenhoefer rašė: >> topo map, or ask virtually any local 'what mountain is that big one?' >> while pointing, and you'll get an answer, but for many of these peaks >> I don't think I've ever seen a sign with the name, so I've been told >> that in such a case the name is not verifiable!) > > IMHO this would represent just a small minority of people thinking so. > Generally verifiability would be satisfied if you could go in the area > and ask the people, there is no requirement for a sign. If there is an official open freely accessible dataset, you (and anybody else) can use it to verify. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Road hierarchy
Well, I would be reluctant to tag the ways leading to this remote house as unclassified or residential: https://openmap.lt/#h/17.01/54.19809/24.27953/0/0/ These are public ways/roads, anybody can use them - they are not private. Yet they are not in the database of Lithuanian road agency, so they are not managed by road agency. Here in Lithuania we have a rule for at least ten years that: if you can see tracks, then it is a track :-) And it corresponds very well to what we see in topographical maps. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Road hierarchy
2019-08-04, sk, 12:59 Florian Lohoff rašė: > If B is a public road A cant be private property and thus not be > a service. If B is a track A can be a service because both > of them share the concept of not beeing for the general public. > > Or vice versa. If you make A a service B cant be a public road. And therefore *track is higher* in the hierarchy than service. Right? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Road hierarchy
All right, let's make it more detailed and more extended. R R RAAA R A R R R R Now A and C are ways leading into the inner territory of residential building(s). But A has another important road B getting out of it, and C does not. Which means A has through traffic while C does not. But all of them are very minor ways visible as two tracks on the ground. Way C is used say twice in a week. Now I would like to skip road C at small scale, but leave A, because I want to leave B. Can we agree on some scheme to tag this (do data augmentation), so that less people doing cartography stuff have to resort to heavy generalisation operation such as road pruning? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Road hierarchy
Let's say we have a residential road R. Going out of this residential road there is a way A into the neighbouring residential area (say 50m length). Out of that way A there is anower way B leading into the fields/forest which lies outside of the residential area. B way is long enough and significant, say leading to some locally significant object (ruins, tree, lake). R R RAAA R A R What could be correct: a) A - service (service=???), B - track (tracktype=???) b) A - track grade1 B - track grade>1 c) others ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Road hierarchy
2019-08-04, sk, 11:56 Erkin Alp Güney rašė: > Paved: service unpaved:track service could always be paved and unpaved. track used to be always unpaved, but somewhere somehow tracktype1 became paved :-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Road hierarchy
2019-08-04, sk, 11:32 Florian Lohoff rašė: > For me unclassified is the same as residential. <...> Ok, so unclassified vs residential is regionally defined, as I wrote. But what about service/track? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Road hierarchy
> Personally, I'd have put residential / living together above unclassified Interesting. Unclassified was always (more than 10 years) defined for "through traffic" which puts it a higher in a hierarchy. From what I understand it was always in the group of primary/secondary/tertiary just the one which does not have an official classification - thus "unclassified". > Once again, personally service before track, maybe further split that > highway=service by itself is higher that the "types" of service road > (driveway, parking aisle etc) This way of interpreting service would make it impossible to identify if missing service=* tag means: 1. missing tag/information 2. specified higher priority service road For example if you have service=driveway and want to make it higher priority service road, you should change service value to something else rather than remove service=* key. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Road hierarchy
Hello Road hierarchy is needed for a number of things: * deciding which classes of roads to display on different scales in a map * performing road network validation * other tasks (f.e. typification of buildings - orientation) Hierarchy would be different in different context: motorcar, bicycle, pedestrian etc. For the time being I'm only asking about motorcars. There is non written (or I could not find in wiki) or "de facto" hierarchy: * motorway * trunk * primary * secondary * tertiary * unclassified * residential * living_street In some regions unclassified has a higher position in hierarchy, in other regions unclassified, residential and living_street have the same position. This is fine for the time being. I'm also intentionally skipping _link classes. My question is about what goes further: track / service Which of them is higher? Does additional tags influence this? For example does adding service=driveway reduce position in hierarchy of service road? Does any value of tracktype change position of track road? And in general, is there a point of agreeing on this globally or it will stay regional anyway? -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] JOSM's "suspicious" path data warnings
2019-07-08, pr, 10:53 Márton Keleti rašė: > I consider using highway=path on urban shared cycle/footways a very bad an > confusing practice. <...> Idea is that path is not only "one man width unpaved" way, but it is also a way where neither footway, nor cycleway fits because the way is for both. This is how it was for many many years (at least 10 years?). It is already used in many many places. It does the job perfectly. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] track smoothness/quality
2019-07-03, tr, 08:04 Mateusz Konieczny rašė: > 2) Take the leading sentence mentioning Solid/Soft out of the tracktype > description (or de-emphasize it) > I am dubious about redefining extremely > popular tags. <...> How come? You are pushing the changing of entire water tagging schema! ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] landuse=reservoir vs water=reservoir
> I find very strange that reservoir is a landuse by itself > it would be a bit like putting landuse=rest on a bench > or landuse=stop on a parking lot. > <...> There are a infinite number of arguments on both sides. Pandora box was already opened and dual standard for water tagging already exists. The fact is that landuse=reservoir was and is used on most reservoirs so it cannot be flagged as "worse". The question is about treatment of these two tags in the wiki. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] landuse=reservoir vs water=reservoir
Hello
landuse=reservoir is from original OpenStreetMap water tagging scheme.
water=reservoir is the newer one ("all blue is natural=water") with
no advantages over previous one. Original (landuse=reservoir) is still
more prominent even with Mapbox/iD's aggressive push for the later
one.
Now OSM wiki for some reason has a note on landuse=reservoir that
"better alternatives exist". Which in my opinion has no base. In my
opinion both reservoir pages must have similar treatment:
1. no "better" (especially if newer and less popular is interpreted
as "better")
2. "alternative" should be mention on both or none of the pages.
What do you think?
--
Tomas
___
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?)
And here the idea of a new separate data layer (as in GIS) for geometries of fuzzy features rises again... Waiting for its time. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Large areas of landuse=grass in the Netherlands
Some time ago I was proposing to introduce topology rules, at least locally. Those (besides a lot of other stuff) would cover which polygons can be above which polygons, which polygons can not be above which polygons etc. Such rules are already used for years in Lithuania in regards of forests. F.e. landuse=forest can not intersect/cover landuse=residential|industrial|commercial|reservoir, natural=water, waterway=riverbank. But for small patches of trees we use natural=wood, which can ONLY be above (be covered by) landuse=residential|commercial|industrial. Idea is that for large scale maps you use all of these polygons (with natural=wood on top) and for small scale maps you simply ignore natural=wood. This simplifies cartographic tasks a lot. It is also capable of separating micromapping without the need for complex generalisation calculations. As far as I understand, landcover tags are supposed to be used for exactly the same tasks (as natural=wood in my example). This means that all natural=wood polygons in Lithuania (not too much - 1500) could be replaced with landcover=wood|forest|trees (whatever) if that was rendered in OSM-Carto, as some people in Lithuania still use OSM-Carto data visualisation and not the local OSM maps. If I understand correctly, landuse=grass is the same thing for grass: landuse=grass is a micromapping (for large scale maps only), landuse=meadow is for smaller scale (actual landuse) mapping. So you could have the same topology rules in Netherlands to check automatically that all landuse=grass is above some actual landuse (hence the need for landcover to be able to have both). This way there would be an automated way to check quality of OSM data. IMPORTANT: There is no way to ensure the quality of OSM data without automated checks doing MOST of the work. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Clarification unclassified vs residential
2019-02-20, tr, 20:08 Florian Lohoff rašė: > From the original meaning unclassified was the lowest class road in > rural or off city limits. residential was the lowest class road within > city limits. (Assuming that city limits mean residential usage) unclassified "original" meaning was "for through traffic". Which is "better", or in normal terminology - "higher in the road network hierarchy". As for the name "unclassified". Both residential and unclassified are roads which do not have national reference numbers/classification. If unclassified and residential would be identical, what would be the reason to tag such roads differently? P.S. Name "residential" is kind of misleading. Because of the lack of highway type for large arteries in industrial/commercial zones, residential is used for that in order not to have just "service" roads, and not to tag them "unclassified" as they are not for through/important/high traffic. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Clarification unclassified vs residential
I would agree with those stating importance of road network hierarchy and connectivity (for both routing and cartography). Having unclassified as higher than residential but lower than tertiary helps a lot. Maybe google will translate this old post with some practical examples and some technical connectivity checking info: https://blog.openmap.lt/2017/12/09/keliu-hierarchija/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tree rows vs individual trees
2019-02-11, pr, 16:26 Ture Pålsson rašė: > That possiblity already exists, as tree_lined=*. However, I believe tree > rows sometimes appear on their own. For example, the tree row in this > picture (which was in the side bar of the Wiki for natural=tree_row) > looks like it is not lining anything in particular: But this is OSM wiki. What about "traditional" cartography? I couldn't find "separate" tree row in topographic maps (last 150 years) of Lithuania, but this could be because such feature is not popular on the ground here. On the other hand, tree rows alongside roads/railroads/canals could be mapped with attribute and separate ones with natural=tree_row object. Individual trees would be very hard to use for such purpose - so useless anyway. > Byt yes, using tree_lined=* when appropriate certainly makes my life as > a renderer developer easier, though I guess it is harder to combine with > also mapping individual trees. :) You will probably skip trees on 25k or 50k? :-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tree rows vs individual trees
2019-02-11, pr, 11:29 Ture Pålsson rašė: > As someone who tries to render smallish-scale (typcally 1:25000 or > 1:5) maps from OSM data, I am always slightly annoyed when someone > states that something does not need to be mapped bacuse it can be > inferred algorithmically from other data, without describing or at least > giving a reference to such an algorithm. > > Tree rows -- real tree rows, i.e. a row of trees planted on purpose to > function as a landscaping feature, not just some random trees which > happen to be in a line -- are important landmarks and often show on maps > as rows of green dots. However, the individual trees are typically too > close to be shown at their real positions, so some generalization is > required. Tagging the tree row provides such a generalization. I have no > doubt that it is theoretically possible to synthesize tree-row objects > from mapped trees, but I would guess that doing so with an acceptable > number of false positives and negatives is close to a masters-thesis > project. Exactly! Two things to add: 1. At least in Lithuania cartographic (topographic) "tree row" is defined as "a row of trees groing alongside a road or railway". That is random trees somewhere in a field do not become a "tree row" even if they are in a row. 2. If (1) is true in other countries, maybe "tree_row" should be an attribute of a road/railroad? Say highway=residential+tree_row=left|right|both. This way it would be much more convenient to create cartographically correct maps in 25k 50k scales without resorting to complex generalisation operations like displacement? -- Tomas ___ 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)
2019-01-10, kt, 10:54 Dave Swarthout rašė: > We just went through a whole discussion about mapping bays as > polygons. (see > https://lists.openstreetmap.org/pipermail/tagging/2018-November/040911.html) > <...> Yes, I agree with everything. You are describing why polygons are needed for labels, you and Martin are describing why it is not practical and what temporary workarounds could be used. Thus my initial note: this is one of the things pushing in direction of creating multiple data layers in OSM (some day in the future, say 2024 :-). ___ 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)
2019-01-10, kt, 09:06 Martin Koppenhoefer rašė: > coding the geometry into the db does not necessarily mean creating polygons > though. > You could also store just 3 nodes and a hint that these are representing a > polygon, to store a triangle (for example). Sorry, I did not get it. How saving only vertexes is better than having a polygon (made out of those vertexes)? Full geometry is required to be able to calculate label positions on all scales. For small scales this could be a simple curved line (calculated from polygon geometry), for large scales it could be a lot of labels placed/scattered on the same polygon geometry and approximating (simplifying) such polygon too much would decrease number of labels placed or labels would be placed outside of an object which is even worse. ___ 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)
2019-01-09, tr, 19:36 Mateusz Konieczny rašė: >> And here we're one more step closer to introducing gis layers in OSM. > > I have no idea how natural=peninsula tagging is related to that. In order to have correct labelling you need polygon geometry for peninsulas (as well as for other objects), but having them in current OSM database is not practical. ___ 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)
And here we're one more step closer to introducing gis layers in OSM. Not there yet, but as maps created from OSM data start aproaching cartographic conventions, the only other way is to use other - non OSM sources. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] My "weirdly unnatural aversion to relations"
2018-09-30, sk, 17:09 Christoph Hormann rašė: > Note this is a completely wrong characterization of the water=* tagging > scheme that is playing on nationalistic sentiments. You should not do > that. Sorry, had no intention to insult anybody. This alternative scheme _originated from Russia_ when standard water schema was already used all around in full toolchain - thus the name. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] My "weirdly unnatural aversion to relations"
On 30.09.2018 05:00, Bryan Housel wrote: > From my own perspective as the main developer on the main editor for > OSM, This is way too exaggerated. While iD is most visible, most data is created not by iD. And it is not always possible to advice novice user to use iD. For example iD only supports new "Russian water tagging scheme" (everything blue is natural=water), so if a country had made a decision to stick with original "standard OSM water scheme" (with landuse=reservoir|basin|etc waterway=riverbank) it is impossible to use iD as it does not support standard OSM water scheme. Note that Russian water scheme never reached the standard water scheme in popularity even with iD pushing for it. Same goes with "contact:*" scheme and probably a number of other tagging schemes. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
