Re: [Tagging] Suggestions for the correct tagging of Field borders
Simon Wüllhorst wrote: I was a bit confused about the inconsistent usage of landuse and natural tag. Sometimes it’s not clear why there is used the natural or landuse key. Landuse and natural tags have different keys, so that you can have both; they describe different properties. It's just that often or sometimes some landuse values virtually always imply some natural elements within that area, so we don't even bother tagging them. E.g. farmland is just landuse=farm, without natural=wheat or similar, or a landuse=quarry is without natural=bedrock or similar. For forrest you have both (landuse=forrest and natural=wood) but it seems to be the only one where you can decide whether it is managed or not. The forest vs. wood is a bad example anyway, since years back somebody made a mass edit and nobody noticed back then that you can have an area used for forestry (landuse=forest), that doesn't have trees (natural=wood) in it for several years; when the area has been clearcut / had a full chop recently. I.e. the combination of tags is not redundant, which was the only reason given for the changes back then. The original way was to use natural=wood with landuse=forest, or by itself; many still use them like that. So, for the field borders, one could pick any or several out of (at least) the following: * natural=scrub * natural=grassland * landuse=meadow (meadows exist that aren't for hay harvesting) * natural=meadow Even other tags may be suitable, depending on local ecological conditions. -- Alv ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Port and terminals
Most ports handle many different types of cargoes, so a single value is insufficient. It would be better to tag the individual terminal objects within a port with a type rather than assign a type to the port object. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Port and terminals
We could use a single polygon per terminal tagged as in the proposal (similar to other landuse types) if we need to go in detail. If needed using also multiple values (http://wiki.openstreetmap.org/wiki/Semicolon) If you read the page you will see that it pretty much says: DON'T USE SEMI-COLONS UNLESS THERE IS NOT OTHER OPTION. http://wiki.openstreetmap.org/wiki/Semicolon#Better_alternatives Would for example work here. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Enhancing natural=peak tag
Hi, 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. *** BTW - my mail was awaiting for admin approval too long, so I canceled it and now I post it again after I subscribed to the list. However there is no hint about subscribing in the proposal guide: http://wiki.openstreetmap.org/wiki/Proposed_features#Proposed -- 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-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
[Tagging] Track grades
Apologies if this is the wrong list, I'm new to the community. On the wiki talk page for tracktype [1] there is some discussion from Australians of this property not properly reflecting road usability. Here in desert New Mexico I am working on significantly improving mapping of tracks, and I have the same problem. Many tracks here are apparently Grade 1 or 2 as they are made up of well-compacted gravel and exposed bedrock. However, due to grade or unevenness they are often unsuitable (and unsafe) for 2WD or low-clearance vehicles. These paths are often quite dangerous to be stuck on, miles away from the nearest person and beyond phone reception. It seems that there are properties to express information like evenness, but they are not taken into account by the standard renderer while the Grade is. Are there any plans to redefine Grade or create a new property for use by renderers that directly expresses the usability of a road? My suggestion would be adding a property (perhaps suitability) with values of 2wd and 4wd, which matches the semantics used by e.g. Forest Service maps which often show 4WD-only tracks with a different line. As a second but similar question, off-highway vehicles are a popular pasttime here and there are many tracks intended for ATVs or dirtbikes, not wide enough for SUVs. Is there a best practice for tagging these types of paths? Thanks! [1] https://wiki.openstreetmap.org/wiki/Key:tracktype Jesse B. Crawford Student, Information Technology New Mexico Inst. of Mining Tech jcrawf...@cs.nmt.edu | je...@jbcrawford.us http://cs.nmt.edu/~jcrawford | http://jbcrawford.us ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Track grades
Hello Jesse, welcome to this list. This is indeed the right list to post this type of questions. However, this question has popped up every few months the past year and so far so consensus has been reached. You can always search the tagging archive and you'll find threads such as https://www.mail-archive.com/tagging%40openstreetmap.org/msg15943.html (this is not the first one in the thread though) regards m On Tue, Jul 8, 2014 at 9:00 PM, Jesse Crawford je...@jbcrawford.us wrote: Apologies if this is the wrong list, I'm new to the community. On the wiki talk page for tracktype [1] there is some discussion from Australians of this property not properly reflecting road usability. Here in desert New Mexico I am working on significantly improving mapping of tracks, and I have the same problem. Many tracks here are apparently Grade 1 or 2 as they are made up of well-compacted gravel and exposed bedrock. However, due to grade or unevenness they are often unsuitable (and unsafe) for 2WD or low-clearance vehicles. These paths are often quite dangerous to be stuck on, miles away from the nearest person and beyond phone reception. It seems that there are properties to express information like evenness, but they are not taken into account by the standard renderer while the Grade is. Are there any plans to redefine Grade or create a new property for use by renderers that directly expresses the usability of a road? My suggestion would be adding a property (perhaps suitability) with values of 2wd and 4wd, which matches the semantics used by e.g. Forest Service maps which often show 4WD-only tracks with a different line. As a second but similar question, off-highway vehicles are a popular pasttime here and there are many tracks intended for ATVs or dirtbikes, not wide enough for SUVs. Is there a best practice for tagging these types of paths? Thanks! [1] https://wiki.openstreetmap.org/wiki/Key:tracktype Jesse B. Crawford Student, Information Technology New Mexico Inst. of Mining Tech jcrawf...@cs.nmt.edu | je...@jbcrawford.us http://cs.nmt.edu/~jcrawford | http://jbcrawford.us ___ 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] Track grades
The combination of tracktype, surface and smoothness could fit the bill. However smoothness values are ill-defined and would need more objective classification, but they also refer to things like high-clearance vehicles see: http://wiki.openstreetmap.org/wiki/Key:smoothness On 8 July 2014 21:14, Marc Gemis marc.ge...@gmail.com wrote: Hello Jesse, welcome to this list. This is indeed the right list to post this type of questions. However, this question has popped up every few months the past year and so far so consensus has been reached. You can always search the tagging archive and you'll find threads such as https://www.mail-archive.com/tagging%40openstreetmap.org/msg15943.html (this is not the first one in the thread though) regards m On Tue, Jul 8, 2014 at 9:00 PM, Jesse Crawford je...@jbcrawford.us wrote: Apologies if this is the wrong list, I'm new to the community. On the wiki talk page for tracktype [1] there is some discussion from Australians of this property not properly reflecting road usability. Here in desert New Mexico I am working on significantly improving mapping of tracks, and I have the same problem. Many tracks here are apparently Grade 1 or 2 as they are made up of well-compacted gravel and exposed bedrock. However, due to grade or unevenness they are often unsuitable (and unsafe) for 2WD or low-clearance vehicles. These paths are often quite dangerous to be stuck on, miles away from the nearest person and beyond phone reception. It seems that there are properties to express information like evenness, but they are not taken into account by the standard renderer while the Grade is. Are there any plans to redefine Grade or create a new property for use by renderers that directly expresses the usability of a road? My suggestion would be adding a property (perhaps suitability) with values of 2wd and 4wd, which matches the semantics used by e.g. Forest Service maps which often show 4WD-only tracks with a different line. As a second but similar question, off-highway vehicles are a popular pasttime here and there are many tracks intended for ATVs or dirtbikes, not wide enough for SUVs. Is there a best practice for tagging these types of paths? Thanks! [1] https://wiki.openstreetmap.org/wiki/Key:tracktype Jesse B. Crawford Student, Information Technology New Mexico Inst. of Mining Tech jcrawf...@cs.nmt.edu | je...@jbcrawford.us http://cs.nmt.edu/~jcrawford | http://jbcrawford.us ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ 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 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] Track grades
Jesse, you are very welcome ! I have campaigned on this topic a couple of times but without really achieving any consensus. Chief problem is some people's fear of 'subjectiveness'. I don't really care exactly how it is done as long as we end up with a clear model advising people whether or not they should attempt a particular road. I have posted references to lost lives as a result of bad decisions. Its easier to get people to take notice of simply presented data. Too much detail scares most people My pet solution was based around tracktype= with two legs, (a) we reassert that tracktype= applies to all highway=, not just highway=track. This was the original intention. (b) extend the five grades by another three, being 4wd recommended, required and extreme. Another approach is to make wider use of 4wd_only=yes. Extend it to have the 'recommended' and 'extreme' values. I was advised that tags starting with a number were a problem in mapnik but others have dismissed that and a new default render has taken over now. I prefer the tracktype= model as it has pretty wide use world wide, 4wd_only= does not yet get much use outside of Australia. Please see Unsealed and 4wd roads in - https://wiki.openstreetmap.org/wiki/Talk:Australian_Tagging_Guidelines Some more ranting on my wiki page (inc discussion) https://wiki.openstreetmap.org/wiki/User:Davo David On Tue, 2014-07-08 at 13:00 -0600, Jesse Crawford wrote: Apologies if this is the wrong list, I'm new to the community. On the wiki talk page for tracktype [1] there is some discussion from Australians of this property not properly reflecting road usability. Here in desert New Mexico I am working on significantly improving mapping of tracks, and I have the same problem. Many tracks here are apparently Grade 1 or 2 as they are made up of well-compacted gravel and exposed bedrock. However, due to grade or unevenness they are often unsuitable (and unsafe) for 2WD or low-clearance vehicles. These paths are often quite dangerous to be stuck on, miles away from the nearest person and beyond phone reception. It seems that there are properties to express information like evenness, but they are not taken into account by the standard renderer while the Grade is. Are there any plans to redefine Grade or create a new property for use by renderers that directly expresses the usability of a road? My suggestion would be adding a property (perhaps suitability) with values of 2wd and 4wd, which matches the semantics used by e.g. Forest Service maps which often show 4WD-only tracks with a different line. As a second but similar question, off-highway vehicles are a popular pasttime here and there are many tracks intended for ATVs or dirtbikes, not wide enough for SUVs. Is there a best practice for tagging these types of paths? Thanks! [1] https://wiki.openstreetmap.org/wiki/Key:tracktype Jesse B. Crawford Student, Information Technology New Mexico Inst. of Mining Tech jcrawf...@cs.nmt.edu | je...@jbcrawford.us http://cs.nmt.edu/~jcrawford | http://jbcrawford.us ___ 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
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
