Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
On Wednesday 09 July 2014, Daniel Koć wrote: [...] It's just my beginnings there, so I'll wait some time before saying anything conclusive, but for now I'm very surprised how the low hanging fruit can be not picked for so long without anybody noticing it, even if all the code is already waiting to be merged ( https://github.com/gravitystorm/openstreetmap-carto/issues/705 ). 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 standard map style but good map design is something that very much needs good coordination for an harmonic overall appearance. This is difficult in an open community approach. 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 to be tested more thoroughly making actual merging of changes into the main style less risky to break things and second it would help making the whole process more democratic since a change that is good and popular and already available to the community will put pressure on the style maintainers to integrate it. Of course such a scenario would require quite significant ressources to implement, it would be a very worthy project for anyone looking for a specific area to support OSM monetarily. Currently the main alternatives to the standard style are the region specific versions created by some local communities (like french and german). Those however are quite specific in aim and are too different from the main style for things to easily be contributed back into the standard style. Also these styles themselves are not really in open development. For me it tells us clearly that at least we should track such things better. If we made just a simple wiki table named Accepted propositions - rendering state with current comments from rendering team (done, todo - from when, wontfix - reasons, undecided - problems to be solved), it could help us connecting loose ends a lot! I can even do it myself, but I need to know it would be used at all. I don't know yet how big is the gap between default tagging and default rendering. 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. [...] I would rather include all such icons in general, because there was a reason somebody wrote it, a community consensus was established and it immediately promotes using such quality-approved tags. If we want to avoid the clutter (which is a noble aim in itself), don't try to avoid it altogether, but rather set the reasonable zoom threshold. sigh 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. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
Thanks for starting this discussion. Personally I think it makes sense to define different types of peaks in the data. It would solve the problem we have now, where tiny hillocks are rendered just like huge mountains. On 8 July 2014 15:14, SomeoneElse li...@mail.atownsend.org.uk wrote: The Proposed_features page seems confused about tagging and rendering though - given that local terrain height is available in most parts of the world from external sources, couldn't a map that wanted to suppress hillocks do so simply by comparing elevation with that? That's not a particularly easy computation to calculate or define. I think in this case, defining this in the tagging is fine. Also, the normal way to define OSM features is by going out and mapping them - so I'd go out and do that first, rather than worry about getting a proposal accepted. For a consistent tagging scheme, I think it's much better to discuss and define things first. OSM needs mappers far more than it needs proposal writers. I strongly disagree with that. -- Matthijs ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
On 9 July 2014 00:05, Daniel Koć dan...@xn--ko-wla.pl wrote: W dniu 08.07.2014 20:04, yvecai napisał(a): However, if rendering is an interesting topic, wiki is full of rendering examples and advices that aren't followed anywhere. Let the You don't even realize how sad is this observation for me... What is the role of writing documentation than - and approving it or declining? You can always use the tags as you like it, and they will be rendered this way or another (or not a all), so why waste the time proposing and documenting? 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). That said, I also don't have problems with a rendering paragraph in the proposal - as long as it's clear that it's meant as illustration of the proposal, and not (directly) as a proposal to change existing rendering. 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). I think your rendering proposal makes sense by the way, but as I said, it's a two step process. Tagging and rendering decisions can (and should) be made independent. But inside the project I think we need some more coherency. If there's an approved proposal with rendering hints, at least the default render should take it into account. I don't think that's necessary, see above. And I see the difference in scale of peaks type, which should be properly visualised to not make default map cluttered with unnecessary details (like https://github.com/gravitystorm/openstreetmap-carto/issues/689 ). Yes, I agree this needs to be solved. -- Matthijs ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
On 9 July 2014 02:56, Daniel Koć dan...@xn--ko-wla.pl wrote: but for now I'm very surprised how the low hanging fruit can be not picked for so long without anybody noticing it, even if all the code is already waiting to be merged ( https://github.com/gravitystorm/openstreetmap-carto/issues/705 ). Two reasons. First, we are trying to clean up current problems with the style sheet first, rather than adding new features. Also, development of the stylesheet has been put on hold for like four years, so there is still quite a large backlog. Second, sometimes things seem easy, while they are not. In the case of fountains, do we really want an icon for every fountain? What about a tiny fountain in someones garden? A small ventilation fountain in a pond? Even for slightly larger public fountains, an icon might attract more attention than it deserved. For me it tells us clearly that at least we should track such things better. If we made just a simple wiki table named Accepted propositions - rendering state with current comments from rendering team (done, todo - from when, wontfix - reasons, undecided - problems to be solved), it could help us connecting loose ends a lot! I can even do it myself, but I need to know it would be used at all. I don't know yet how big is the gap between default tagging and default rendering. First of all, we are past the state where every tag can be rendered. For example, I believe that fire hydrants are an officially accepted tag. That doesn't mean that we should render them on openstreetmap-carto. Same thing for underground cables, etc. However, if you could create a table on the wiki that links accepted features to their Github id (if existing), that would be helpful, I think. But as I said, the focus at the moment is not on adding features - but that might change in a couple of months. By the way, the number of features officially accepted is surprisingly small. For example, there are only about 5 officially accepted shop types (but much more implicitly accepted ones, of course). the remark about the carto not being made for all the POI icons was against my intuition. If I understand Andy correctly, he exaggerated a bit in order to direct developer effort towards fixing the features we currently have, rather than adding new features. As I said, we started with quite a mess (and some areas of the code still are, although it's much better than two years ago), it's better to fix these first before adding new stuff to the mess. I would fully agree if that meant simply there's more to rendering than POI's, but I'm not sure. I would rather include all such icons in general, because there was a reason somebody wrote it, a community consensus was established and it immediately promotes using such quality-approved tags. If we want to avoid the clutter (which is a noble aim in itself), don't try to avoid it altogether, but rather set the reasonable zoom threshold. I don't think for example fire hydrants should be rendered at any zoom level. About which POI to render and which not, see also the discussion I tried to start here: https://github.com/gravitystorm/openstreetmap-carto/issues/660 -- Matthijs ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
2014-07-09 13:39 GMT+02:00 Christoph Hormann chris_horm...@gmx.de: 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. +1. These are really two different aspects, because the tagging has the aim to give a short, detailed, precise, specific description of something (and so allows distinction from something different). Rendering instead tries to show what might be interesting for a given context (i.e. it will be a selection and generalization of all the information contained in the db). There is only one tagging/mapping db, but there are infinite rendering dbs. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
W dniu 09.07.2014 17:01, Martin Koppenhoefer napisał(a): +1. These are really two different aspects, because the tagging has the aim to give a short, detailed, precise, specific description of something (and so allows distinction from something different). And then sometimes you end up with rendering problem because of lack of enough distinction in the tagging (they are by your definition not what they really should be), and what than? I would get back to tagging studio and think if this visual distinction is not a symptom of a more fundamental difference, which should be seen in tagging. And you? Rendering instead tries to show what might be interesting for a given context (i.e. it will be a selection and generalization of all the information contained in the db). There is only one tagging/mapping db, but there are infinite rendering dbs. That's true for many themed maps, where the context is king, but I talk only about default one. And there are also many wild tags out there (and I don't touch them), but only one default set, and it is what I want to talk about. This set is not too big, yet the default map doesn't show all these default tags. I feel it's a bad quirk. -- Mambałaga ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
2014-07-09 18:51 GMT+02:00 Daniel Koć dan...@xn--ko-wla.pl: And then sometimes you end up with rendering problem because of lack of enough distinction in the tagging (they are by your definition not what they really should be), and what than? I would get back to tagging studio and think if this visual distinction is not a symptom of a more fundamental difference, which should be seen in tagging. And you? Yes, I also find a lot of such situations where there aren't yet tags for details I'd like to convey or even whole object classes missing. I often write proposals and hope that others catch them (e.g. amenity=monastery is one of these, where before many mappers insisted that tagging them as place_of_worship would suffice but now it seems that the tag gets used also by others). Rendering instead tries to show what might be interesting for a given context (i.e. it will be a selection and generalization of all the information contained in the db). There is only one tagging/mapping db, but there are infinite rendering dbs. That's true for many themed maps, where the context is king, but I talk only about default one. And there are also many wild tags out there (and I don't touch them), but only one default set, and it is what I want to talk about. This set is not too big, yet the default map doesn't show all these default tags. I feel it's a bad quirk. there was some pause with the main stylesheet until last year, but now there is great activity and a lot of things get touched (and amended). Be confident, the main style is improving rapidly and open to everyone to create pull requests. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
2014-07-08 15:59 GMT+02:00 Daniel Koć dan...@xn--ko-wla.pl: I just made the proposal page for discussion about enhancing natural=peak tag: http://wiki.openstreetmap.org/wiki/Proposed_features/peak This is my first attempt to define OSM features. I am not sure this is something we'd want in OSM for at least 2 reasons: 1. As you (and wikipedia) write, there is no clear distinction between mountain and hill, so this is subjective (you write it in the proposal) 2. The analysis of the other peaks in the area and the topography in general can be done automatically both, based on OSM data and on additional elevation data (like from hgt rasters, Aster, SRTM, other DEMs, etc.) So this is probably not something we'd have to map manually, as it could be automatically derived. I agree that the current rendering is not always optimal, but this could be resolved in the rendering system, no need to do it in the base data. Or maybe I got you wrong? Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
Am 08.07.2014 17:06, schrieb Martin Koppenhoefer: 2014-07-08 15:59 GMT+02:00 Daniel Koć dan...@xn--ko-wla.pl mailto:dan...@xn--ko-wla.pl: I just made the proposal page for discussion about enhancing natural=peak tag: http://wiki.openstreetmap.org/__wiki/Proposed_features/peak http://wiki.openstreetmap.org/wiki/Proposed_features/peak This is my first attempt to define OSM features. I am not sure this is something we'd want in OSM for at least 2 reasons: 1. As you (and wikipedia) write, there is no clear distinction between mountain and hill, so this is subjective (you write it in the proposal) 2. The analysis of the other peaks in the area and the topography in general can be done automatically both, based on OSM data and on additional elevation data (like from hgt rasters, Aster, SRTM, other DEMs, etc.) So this is probably not something we'd have to map manually, as it could be automatically derived. I agree that the current rendering is not always optimal, but this could be resolved in the rendering system, no need to do it in the base data. Or maybe I got you wrong? If you really want to get some useful information in the data you could have a look at topographic prominence [1] and isolation [2] (german page is much better). Though, Martin is right that this information could be automatically calculated. Cheers fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
Am 08.07.2014 17:52, schrieb fly: Am 08.07.2014 17:06, schrieb Martin Koppenhoefer: 2014-07-08 15:59 GMT+02:00 Daniel Koć dan...@xn--ko-wla.pl mailto:dan...@xn--ko-wla.pl: I just made the proposal page for discussion about enhancing natural=peak tag: http://wiki.openstreetmap.org/__wiki/Proposed_features/peak http://wiki.openstreetmap.org/wiki/Proposed_features/peak This is my first attempt to define OSM features. I am not sure this is something we'd want in OSM for at least 2 reasons: 1. As you (and wikipedia) write, there is no clear distinction between mountain and hill, so this is subjective (you write it in the proposal) 2. The analysis of the other peaks in the area and the topography in general can be done automatically both, based on OSM data and on additional elevation data (like from hgt rasters, Aster, SRTM, other DEMs, etc.) So this is probably not something we'd have to map manually, as it could be automatically derived. I agree that the current rendering is not always optimal, but this could be resolved in the rendering system, no need to do it in the base data. Or maybe I got you wrong? If you really want to get some useful information in the data you could have a look at topographic prominence [1] and isolation [2] (german page is much better). Though, Martin is right that this information could be automatically calculated. Cheers fly Sorry forgot the links: [1] https://en.wikipedia.org/wiki/Topographic_prominence [2] https://en.wikipedia.org/wiki/Topographic_isolation ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
W dniu 08.07.2014 16:14, SomeoneElse napisał(a): Currently taginfo suggests almost no usage of peak like this http://taginfo.openstreetmap.org/keys/peak#values Yes, but that's exactly where the problem is: I think people are simply cheating now. =} They see no other peak tags in wiki, so they use just the one they see. Using natural=peak almost everywhere instead of man_made=peak, when that would be the most reasonable way to tag, make me think this way. and see also: http://taginfo.openstreetmap.org/tags/natural=peak#combinations There's nothing interesting IMHO - name, ele etc. are all OK, but they don't help with the problem. The Proposed_features page seems confused about tagging and rendering though - given that local terrain height is available in most parts of the world from external sources, couldn't a map that wanted to suppress hillocks do so simply by comparing elevation with that? I'm not sure why you'd need to tag the height of things around thing A on thing A itself. I think tagging, documentation and rendering are somehow intertwined. That's why people are cheating. It's very tempting to have peak visible through natural=peak even if you know for sure it's not natural. So let's look the other way: why we tag the mountain peaks, in the first place, if it's even more simple to identify them by comparing elevation than hills and hillocks? Additional (general) problem is we have poor terrain representation. On the main page only the OpenCycleMap has this kind of data visible, but from what I saw it's effective only for high mountains. For micromapping it just doesn't work at all. Also, the normal way to define OSM features is by going out and mapping them - so I'd go out and do that first, rather than worry about getting a proposal accepted. I'm not that worried - if people won't accept it, it just won't be accepted and I can live with that: maybe I am totally wrong or that is not the best way of dealing with my problem? Go and tell me! What worries me more is that I don't really know how to clearly show how complex this problem is. It's not only about tagging documentation, but also good elevation/shading background, tags rendering and people behavior. There may be even more! =} start from here if I were you) but it's not meant to be - OSM needs mappers far more than it needs proposal writers. If you think that it's important to classify a natural=peak as a hillock go and have a look at it, and if it looks like a hillock to you, tag it as one! Well, I am the active mapper for years now =} , but that's the wall I hit when micromapping and I try to fix it. I see this proposal as the next level of scratching my itch, not leaving the base work. -- Mambałaga ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
On Tuesday 08 July 2014, fly wrote: Sorry forgot the links: [1] https://en.wikipedia.org/wiki/Topographic_prominence [2] https://en.wikipedia.org/wiki/Topographic_isolation http://wiki.openstreetmap.org/wiki/Proposed_features/key:prominence This can be calculated automatically in principle but doing this in the general case is very expensive so it would make sense to record this information in the database. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
Calculating relief features from a DEM is doable. Naming them is not. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
This proposal is not a bad idea: refining an existing tag can't do no harm. However, if rendering is an interesting topic, wiki is full of rendering examples and advices that aren't followed anywhere. Let the renderer render and the cartographer style the map, and trust them to understand tags of interest to them. Yves ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
W dniu 08.07.2014 18:50, Martin Koppenhoefer napisał(a): the tag, i.e. I would deliberately choose natural=peak for all kind of peaks and hilltops regardless their (geological) history. If someone took off some stones from a natural peak it would become a man made peak for you and you'd tag it differently? Well, exactly! =}}} And it's not just me - they are also important all over the world and have many purposes for quite a long time: http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dcairn https://en.wikipedia.org/wiki/Cairn Moreover, mounds are artificial (man/aliens made? =} ) peaks by definition: A mound is an artificial heaped pile of earth, gravel, sand, rocks, or debris. [ https://en.wikipedia.org/wiki/Mound ] *** The natural/man_made dilemma looks silly on the surface, but is very deep rooted. We started with some general, light-weight ontology, which was enough for the beginning. But now we are no more just the OpenStreetMap, rather (The)OpenWorldMap. We got used to some old habits - like the very name of the project - but some cracks start appearing here and there. We just keep extending some tags just by historical reasons, not their merits (highway=bus_stop anyone?...), but it doesn't have to stay that way forever (public_transport=* namespace!). If I was to define peak now, I would start with terrain=peak, and then add descent=natural or descent=artificial to narrow it down when needed. Sorry for such a big vision, but this list description allows us to talk about tag strategy. =} -- Mambałaga ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
W dniu 08.07.2014 20:25, Martin Koppenhoefer napisał(a): I agree, man_made=mound isn't a bad idea. Great, feel free to make such amendments! My original proposition is rather wide, since I'm not familiar with many types of terrain objects and don't want to pretend I get the whole picture. Discussion about it learns me something. I wouldn't question all peaks and require a subtag like descent=natural for what can and has in the past sufficiently been described with natual=peak. If there are a few mounds between the currently tagged objects, you can always retag those few, but retagging all peaks because there are some questionable ones between them is not a good idea (IMHO). I wrote about how it should be done right, while you talk about problems with changing what we have now, and that's a bit different question. I don't know how far we should go to make these whole terrain matters sane, but if we feel it really needs serious surgery, than the transition problems will arise inevitably. They are one of the main reasons why we have historical luggage at all (the other one is people getting used to some quirks). If we would plan this transition, there are few possible strategies to take: 1. Convert all natural=peak into terrain=peak+descent=natural, because this is the most accurate and conservative tag translation. 2. Convert all natural=peak into terrain=peak and leave the descent key to be filled later, because we're not sure what the peak descent really is, as the natural namespace was already overloaded/abused (that is the strategy I would choose). 3. Don't convert anything, since we know this is important tag and a rendering implementation will lag - just add a new tag to the previous one. Then we could also overuse existing top-level natural=peak and man_made=peak instead of (IMHO better) lower-level descent=* key. 4. Convert all natural=peak into natural=terrain+terrain=peak and also define man_made=terrain or allow a little strange tagging: natural=terrain+terrain=peak+descent=artificial. So we have many ways to resolve this. But I'm more interested in rethinking actual state of things as much, as it's possible, and only than think about how to make it technically. I know terrain in OSM is a broad topic, but I think it's time to touch it at least. Tagging it will be just the outcome of the choosing the right mental model. I have tagged many of them with historic=tomb and tomb=tumulus (and eventually also with building=tumulus) but they can also be considered mounds. Hm, not all the mounds are tombs. *** BTW: Did you know the http://openworldmap.org leads to http://openstreetmap.org? Looks like I was not the first who thinks about better name of the current project. =} However http://openworldmap.com/ is some crazy commercial entity using OSM data... -- Mambałaga ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
W dniu 08.07.2014 20:04, yvecai napisał(a): However, if rendering is an interesting topic, wiki is full of rendering examples and advices that aren't followed anywhere. Let the You don't even realize how sad is this observation for me... What is the role of writing documentation than - and approving it or declining? You can always use the tags as you like it, and they will be rendered this way or another (or not a all), so why waste the time proposing and documenting? renderer render and the cartographer style the map, and trust them to understand tags of interest to them. You have no choice but to trust external rendering services - they will do what they think is important anyway. And we show this trust by OSM license. But inside the project I think we need some more coherency. If there's an approved proposal with rendering hints, at least the default render should take it into account. Ideally I think all such features should be rendered - and if not, the documentation should be revised by rendering team explaining what is the problem. Eventually the consensus can be reached. Otherwise, if OSM is basically the GIS database, why the main project page has the map instead of big red Download the data! button? In my case it was as simple as taking the template and filling it up. Rendering section in this template (and the field in the proposition infobox) means it's not unusual that the tagging can have rendering implications. And I see the difference in scale of peaks type, which should be properly visualised to not make default map cluttered with unnecessary details (like https://github.com/gravitystorm/openstreetmap-carto/issues/689 ). But I just gave rough idea - the rendering team may feel some other settings would be better. -- Mambałaga ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
Daniel, I don't know about standardization of rendering, but I would say the advice on the wiki is followed by OSM mappers much more often than some veterans think. 2014-07-08 20:05 GMT-03:00 Daniel Koć dan...@xn--ko-wla.pl: W dniu 08.07.2014 20:04, yvecai napisał(a): However, if rendering is an interesting topic, wiki is full of rendering examples and advices that aren't followed anywhere. Let the You don't even realize how sad is this observation for me... What is the role of writing documentation than - and approving it or declining? You can always use the tags as you like it, and they will be rendered this way or another (or not a all), so why waste the time proposing and documenting? renderer render and the cartographer style the map, and trust them to understand tags of interest to them. You have no choice but to trust external rendering services - they will do what they think is important anyway. And we show this trust by OSM license. But inside the project I think we need some more coherency. If there's an approved proposal with rendering hints, at least the default render should take it into account. Ideally I think all such features should be rendered - and if not, the documentation should be revised by rendering team explaining what is the problem. Eventually the consensus can be reached. Otherwise, if OSM is basically the GIS database, why the main project page has the map instead of big red Download the data! button? In my case it was as simple as taking the template and filling it up. Rendering section in this template (and the field in the proposition infobox) means it's not unusual that the tagging can have rendering implications. And I see the difference in scale of peaks type, which should be properly visualised to not make default map cluttered with unnecessary details (like https://github.com/gravitystorm/openstreetmap- carto/issues/689 ). But I just gave rough idea - the rendering team may feel some other settings would be better. -- Mambałaga ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
W dniu 09.07.2014 2:56, John Packer napisał(a): Daniel, I don't know about standardization of rendering, but I would say the advice on the wiki is followed by OSM mappers much more often than some veterans think. Still there are some notable cases when they're not. I wouldn't be interested in rendering now if I didn't have my favorite problems with it lasting for months or years, even those easy to fix. That includes fountains and at least rudimentary public_transport namespace representation - these are just examples I personally need and it wouldn't hurt anyone. I try not to be overly negative with it (no matter how irritated I feel sometimes as a mapper =} ) and go the positive way, so I get involved in openstreetmap-carto. It's just my beginnings there, so I'll wait some time before saying anything conclusive, but for now I'm very surprised how the low hanging fruit can be not picked for so long without anybody noticing it, even if all the code is already waiting to be merged ( https://github.com/gravitystorm/openstreetmap-carto/issues/705 ). For me it tells us clearly that at least we should track such things better. If we made just a simple wiki table named Accepted propositions - rendering state with current comments from rendering team (done, todo - from when, wontfix - reasons, undecided - problems to be solved), it could help us connecting loose ends a lot! I can even do it myself, but I need to know it would be used at all. I don't know yet how big is the gap between default tagging and default rendering. Yesterday I have watched Andy's workshop ( http://blog.gravitystorm.co.uk/2014/07/07/openstreetmap-carto-workshop/ ) and while it was very interesting for me, the remark about the carto not being made for all the POI icons was against my intuition. I would fully agree if that meant simply there's more to rendering than POI's, but I'm not sure. I would rather include all such icons in general, because there was a reason somebody wrote it, a community consensus was established and it immediately promotes using such quality-approved tags. If we want to avoid the clutter (which is a noble aim in itself), don't try to avoid it altogether, but rather set the reasonable zoom threshold. I hope these are things we can fix soon, but for now some visible problems are still unresolved. -- Mambałaga ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
