[Tagging] Tagging-rendering relations
W dniu 09.07.2014 13:39, Christoph Hormann napisał(a): I can very much relate to that but this is not a matter that can be resolved easily. Everyone has things he/she likes to change in the Of course, but even open projects are not completely disconnected and we can try to find a good balance. My opinion is that the best approach would be to establish better means for people to create variants of the style and present them to a broad audicence. This would have two effects - first it would allow changes That would be awesome! However in the meantime we can also make baby step in this direction: default beautiful map (current stable one) and default testing map, where we can have also all the default icons to cherry pick the best approach and use them later in the beautiful style. What do you think about it? In general a good tagging scheme should stand alone and not be designed specifically for a certain rendering. To this aim it is quite good not to have a too close connection between tagging and rendering. A tag that contains useful and specific information can also be useful in rendering even if the actual way it is rendered is not considered during tag design. In ideal world DTP (I do it sometimes) doesn't need to be checked by the authors, but in reality some hints are even helpful for the best end result, because documents rarely are self-explanatory. Also the remarks from DTP operator help authors to choose easier ways of doing something. I said before, that I treat Rendering option as a hint for rendering team, not a duty, so I can agree with you. That is not too close connection, but a two-way communication interface: I said also, that rendering team can express their views and try to reach the common ground or just clearly state the reasons of a difference. Rendering issues can also convince the proposition author to rethink the tagging rules - it's just one more input in the brainstorm. I can't think of it as a problem at all. Total separation is needed to make something more secure, not more useful, especially in open projects, where we choose project roles as we like it and can have more than one at the time. Fixed zoom threshold are one of the major problems of the current map style, they are selected to look fine for a certain area, usually the favorite city of the one making the style decision. Choose a different area where the map scale is different or the geographic setting leads to a different distribution of POIs and things fall apart quickly. So are fixed highways classification: primary road in rural countries can look like a track in developed ones... But it's just the cost of trying to make things consistent in global scale, not the specific rendering issue and we can't fully get rid of it. Maybe we have to make some local rules too, but than we loose a bit of uniformity - and we can look for the best balance between those things. But in the model with stable and testing default map we can put everything to testing and see if it works or not. Even if we will hit the wall hard with some cases, the good ones won't be stopped from being used in the stable and if someone likes to see everything and more, she will have the option to do it. -- Mambałaga ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Tagging-rendering relations
W dniu 09.07.2014 14:01, Matthijs Melissen napisał(a): I think it's best to think of it as a two step process: first propose the tags that describe the reality (here), then propose how they should be rendered (on the openstreetmap-carto Github). Well, as I said: in my proposition I did _nothing new_ at all! The rendering hints are in the proposition's template. So the process part in the tagging dept is already well defined: if you have some hints about rendering, say it here!. What we lack, however, is the part of the tagging interpretation process in the rendering dept. Default tagging is clearly documented and community voted, but default rendering decisions are not even documented and are not even being talked-back. They just happen in the form of issue tickets and the code. So what I like to do is to store those decisions somewhere - and I think using already existing tagging dept documentation has additional profits for the project in the form of synchronizing both depts docs. I will say it again, because I feel the fear of mixing everything: syncing docs is not about doing everything together! The tagging dept decisions may be completely different than rendering dept, but at least we can see (a) what are those decisions and (b) why the differ. Both tagging and rendering discussions are already difficult enough as they are - separation of concern simplifies the discussion (also, some people are only interested in rendering and others only in tagging). Of course they are somehow separate, but the bad thing is they don't ever communicate with each other. If someone is not interested in the second dept, she can easily skip this section, but if someone else wants to know how both depts relate to each other, he has no clue - he can only look at the map and search through the carto tickets in the hope the subject was already discussed. The link for the proper ticket in the Rendering section would hurt no animal. The list of tagging-rendering decisions can help the carto team to have broader picture what is done, what should be, what will not be done, and what can-be-done-if-something-else-is-done-before. I hope that sounds less scary. =} -- Mambałaga ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging-rendering relations
On Wednesday 09 July 2014, Daniel Koć wrote: My opinion is that the best approach would be to establish better means for people to create variants of the style and present them to a broad audicence. This would have two effects - first it would allow changes That would be awesome! However in the meantime we can also make baby step in this direction: default beautiful map (current stable one) and default testing map, where we can have also all the default icons to cherry pick the best approach and use them later in the beautiful style. What do you think about it? This would still require significant additional ressources including the workload of managing two separate styles. I don't think testing is the problem here, those involved in the standard style design have testing environments. The key is to enable more people to try out new things and allow them to communicate and share their results. Fixed zoom threshold are one of the major problems of the current map style, they are selected to look fine for a certain area, usually the favorite city of the one making the style decision. Choose a different area where the map scale is different or the geographic setting leads to a different distribution of POIs and things fall apart quickly. So are fixed highways classification: primary road in rural countries can look like a track in developed ones... But it's just the cost of trying to make things consistent in global scale, not the specific rendering issue and we can't fully get rid of it. Maybe we have to make some local rules too, but than we loose a bit of uniformity - and we can look for the best balance between those things. No, you are then mixing tagging and rendering which as i said is a really bad idea. Which roads get certain tags should be based on universal, objective rules based on properties of the object 'in the field', verifiable by any mapper through observation of the road in question. Making sure these roads are shown in a well readable way in the map based on the neutral, verifiable information stored in the tags and possibly other data is task of the map designer. This is often difficult since for good results map rendering has to take a lot of context into account (like if a road is in an urban or rural setting). But rigging the tagging rules to spare the map designer this work (what you call 'rethink the tagging rules' based on 'rendering issues') is counterproductive since it devalues the data stored in the tags. To get back to the original topic of this thread - you can of course try to make a distinction between hills and mountains through tagging and for this to be useful data you establish some prominence threshold. Then you say mountains should be displayed at z10 and hills only at z15 (or whatever) - i can assure you if this works well in the Netherlands it won't work in Switzerland and if it works in Peru it won't work in Greenland (or the other way round - depending on your choices). Then you create a table on the wiki with distinct rules for what to tag as mountain/hill for every country of the world which might - if followed diligently by the mappers - lead to a halfway decent rendering result in small, homogeneous countries. But as a result the tags are essentially useless to actually tell anything substantial about the peak in question. I am sorry if this sounds like a rant but there are simply so many tags used a lot but completely useless in terms of informational value exactly because of this. Please just make sure you do not fall into this trap with your peak=* concept. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging-rendering relations
2014-07-09 17:24 GMT+02:00 Daniel Koć dan...@xn--ko-wla.pl: I think shop=* key should be always rendered - HOT has nice basket icon for that. What makes some types of shops better than the others? the idea to use a whitelist is to avoid rendering objects with syntax errors in the tags, because this gives the mappers feedback that there is indeed a problem if something is not rendered... cheers. Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging-rendering relations
On 9 July 2014 16:57, Martin Koppenhoefer dieterdre...@gmail.com wrote: the idea to use a whitelist is to avoid rendering objects with syntax errors in the tags, because this gives the mappers feedback that there is indeed a problem if something is not rendered... That said, we are planning to render far more shops than we currently do: https://github.com/gravitystorm/openstreetmap-carto/pull/117 -- Matthijs ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging-rendering relations
W dniu 09.07.2014 16:56, Christoph Hormann napisał(a): This would still require significant additional ressources including the workload of managing two separate styles. I don't think testing is the In my vision testing would be not very much different, but include all the standard tags we have agreed upon. problem here, those involved in the standard style design have testing environments. The key is to enable more people to try out new things and allow them to communicate and share their results. You talk only about developers, but what about ordinary mappers with no such skills? How that may attract them to communicate their thoughts and needs? Testing style plus feedback on the tag documentation would do, IMHO. No, you are then mixing tagging and rendering which as i said is a really bad idea. Which roads get certain tags should be based on I don't agree with what you said here: not mixing, but communicating and (sometimes, when it makes sense!) influencing. universal, objective rules based on properties of the object 'in the field', verifiable by any mapper through observation of the road in question. Making sure these roads are shown in a well readable way in You will always fall in the trap of localities when working on a global level, there's no escape - sorry... And which mapper? Our polish team wants to go mapping to Kazakhstan and what they see as under-track by our standards is the best road one can get there. So you have to cheat one way (what observer sees) or another (what he knows). The standards are just very different and we can't make them uniform. But rigging the tagging rules to spare the map designer this work (what you call 'rethink the tagging rules' based on 'rendering issues') is counterproductive since it devalues the data stored in the tags. Where did I say the tagger has to spoil the precious data on renderer demand? If you rethink there's no guarantee you will agree. But you may. There is no fixed duties in communication! And reality check is a common way of testing abstract designs. Do you still find it a bad thing? Then you say mountains should be displayed at z10 and hills only at z15 (or whatever) - i can assure you if this works well in the Netherlands it won't work in Switzerland and if it works in Peru it won't work in Greenland (or the other way round - depending on your Yes, sure, but the same is true for almost every item. The mountain peaks are different in different locations. There are place, where there's plenty of them, and where there's nothing at all. And what do we do about it now? Nothing, it's just the reality. In the center of city we have so many shops that they make a nasty mess on default map and I have to look at humanitarian's additional zoom level to use it reasonably. What would you do about that, knowing that in many other places in the world (including a street around a corner) the shop density is not so high? Diversity and a scale issues are two things we should always have in mind, even doing good, old, straightforward, big mapping. I am sorry if this sounds like a rant but there are simply so many tags Yes, for me it really does sound like that, but at least nobody here claimed my opinion is a trolling, as it was once when I was discussing it on our country forum. =} I was almost sure I touch some edgy stuff, though it's not what is on my mind - I just want to fix the issues I see. used a lot but completely useless in terms of informational value exactly because of this. Please just make sure you do not fall into this trap with your peak=* concept. It was exactly the wall I hit hard originally. When micromapping I clearly see the informational value of even 2 m small, but tall peak, just as with other terrain objects (cliffs, saddles, embankments etc.) and amenities of the same scale (bollards, lamps, trees, garages, trash bins). But one can't see this value when sitting on the mountain - and it's hardly surprising. There is a fear that this small, nasty peaks will spoil our mountains (no, I don't make it up!). And the need to defeat it. And who could ever care for such a small details? And it was always like this, so how came it is needed now? And we don't have good terrain model in project. And... etc. -- Mambałaga ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging-rendering relations
On 09/07/2014 16:39, Matthijs Melissen wrote: On 9 July 2014 16:24, Daniel Koć dan...@xn--ko-wla.pl wrote: W dniu 09.07.2014 14:19, Matthijs Melissen napisał(a): So - what about making the testing map and adding there all the already documented features for the start? Maybe we should discuss it elsewhere, because we're far from the tagging: what is a better place - talk list or maybe carto issue tracker? I think either the talk or the dev list. What you propose sounds like a fork of the carto-stylesheet, so would by definition be out of scope of the issue tracker. Historically, the standard style was a for mappers style - it was designed to show features that mappers had mapped. That has been changing (largely without community involvement or review). I tried to kick off discussion here: https://lists.openstreetmap.org/pipermail/talk/2014-June/070074.html and would have welcomed input from the people changing the standard style from its previous purpose to explain exactly what they thought that the standard style was _for_. Unfortunately, none was forthcoming. I would certainly welcome (on the talk list rather than the tagging list) some information about what the group of people currently editing the standard style are actually trying to achieve with it. It seems like the end goal is something a bit like what the Mapquestion Open style already provides (a summary of road information, not much else), which seems a curious design decision given that Mapquest Open tiles are already available as a style on the front page. Cheers, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging-rendering relations
2014-07-09 18:24 GMT+02:00 Daniel Koć dan...@xn--ko-wla.pl: You will always fall in the trap of localities when working on a global level, there's no escape - sorry... And which mapper? Our polish team wants to go mapping to Kazakhstan and what they see as under-track by our standards is the best road one can get there. So you have to cheat one way (what observer sees) or another (what he knows). The standards are just very different and we can't make them uniform. maybe you have to make up your mind about highway=track, as this is not something reflected by surface quality. If it is a road, it is not a track, a track becomes a track by use / dedication cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
