Re: [Tagging] Feature proposal - Power transmission refinement - RFC 2
Hi Alv, I'm sorry this particular point disappoint you and be such a disagreement reason. Our views aren't the same regarding power line model and they do have been well explained on wiki and on this mailing list (and on the gravitystorm's github indeed). JOSM already asking you a voltage=* tag on any power=* object. Let's allow voting people to give their position when second vote will be open. Cheers. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com 2014-07-09 9:44 GMT+02:00 Kytömaa Lauri lauri.kyto...@aalto.fi: François Lacombe wrote: I spent a little more time this week on the power transmission proposal. https://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement Finally, the two values minor_line and minor_cable, due to the arbitrary voltage threshold which may be different for every contributor, should be replaced by power=line + voltage=* or power=cable + voltage=* to let every consumer to set up its own threshold. https://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement#overhead_power.3Dline Calling it replacement doesn't mean it's not deprecation. The proposal is still trying to deprecate power=minor_line, and to remove the simple physical distinction between really big thing on big pylons vs. smaller overhead lines that you can often find everywhere. Mappers can make that size distinction much easier and faster than they could estimate what the actual voltage happens to be; the size is the criteria, not the voltage, even if the size quite often exceeds the threshold after some value in any particular country. And that classification is the most prominent feature for everybody else not interested in the voltages or circuits or number of cables or whatever; in mostly incomplete areas, mappers are most likely to first draw only the big things, and only then start adding the minor_line's, so it's even easier to use the right choice. Pnorman provided you with nice example pictures for the distinction on the rendering github pages, and gravitystorm explained in detail in another issue in the same tracker why arbitrarily changing established tags is bad for the community. It should be a lesser inconvenience for power infrastructure consumers to select where (power=line or power=minor_line) and voltage= etc., than it would be for every other existing map to be cluttered with prominent power lines crisscrossing the suburbs and countryside until all eternity (entering a voltage=* tag can never be enforced on mappers). -- Alv ___ 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
On Tue, Jul 8, 2014 at 9:39 PM, Volker Schmidt vosc...@gmail.com wrote: The combination of tracktype, surface and smoothness could fit the bill. You cannot expect that any renderer will be able to display all possible combinations of these three keys and dozen values. Or you map is unreadable. However smoothness values are ill-defined and would need more objective classification, but they also refer to things like high-clearance vehicles http://wiki.openstreetmap.org/wiki/Key:smoothness Excepted if you can provide a special device measuring the road smoothness, it will never be objective. Forget the smoothness tag please. We might replace it by the 4wd tag (but it's only a partial solution) or another passable tag (for city car, 4wd, mtb, etc) Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
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
[Tagging] tree shrines
Wayside shrines and crosses are quite common here in Austria, and probably in other parts of Europe too. They are mounted on posts (or pillars, walls...) made of various materials (wood, stone...), or on trees. When mounted on trees, I use a tag combination of historic=wayside_cross (or _shrine) with natural=tree + species=* etc. and (if applicable) name=*. I mapped a lot of these that way. Therefore I felt kind of annoyed when someone created a wiki page for the new and apparently synonymous tag historic=tree_shrine and immediately added it to the map features without any preceeding usage or discussion. I contacted him, but we didn't achieve a consensus. In order to untangle that tagging issue, I would like to ask native English speakers for their understanding of terms: - How do you call a cross at a tree? - How do you call a picture of a saint, or other shrine-like object, at a tree? - Is the term tree shrine common? - Is it considered a subset of the term wayside shrine, i.e. can you refer to a tree shrine as a wayside shrine? If we come to the conclusion that tree shrine is the correct term and that we therefore ought to tag them as historic=tree_shrine, some further questions arise: - Does it apply to crosses as well, or only to pictures and alike? - Does historic=tree_shrine imply natural=tree? - Is name=* the name of the tree or the name of the shrine/picture/cross? What if they differ? - Is start_date the birthdate of the tree or the date the shrine was made? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ 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
[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
Re: [Tagging] Feature proposal - Power transmission refinement - RFC 2
On Jul 9, 2014, at 2:07 AM, François Lacombe wrote: JOSM already asking you a voltage=* tag on any power=* object. Which I, as a mapper more interested in roads and trails, ignore as I don't know what to put there and I'd rather have nothing than something that is wrong. Many of the larger power lines (in a physical sense if not an electrical power sense) on large metal pylons are visible on satellite imagery, but their voltage isn't. So an arm chair mapper can show the location but not the voltage. When hiking or driving I can see the local power poles and sometimes guess if they carry power or communications cables or both. And I can see and make the distinction between a power line that is on large metal pylons and others. Since some of these items are really useful as navigation landmarks in undeveloped areas, I map them as I can. But that mapping will never include voltage, whether it is AC or DC, etc as I don't know and have no easy way to find out. Cheers! ___ 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
[Tagging] Tag for toilet with ostomate/stoma equipment
Hi, Please let me clarify how to be tagged toilets for ostomate/stoma equipment is settled. Here in Japan, some public toilets have such a equipment. http://ja.wikipedia.org/wiki/%E3%82%AA%E3%82%B9%E3%83%88%E3%83%A1%E3%82%A4%E3%83%88 I think it is better to be tagged like wheelchair =[yes|no] tag. Any suggestion? Followings are comes to my mind. e.g. ostomy_irrigation = [yes|no] toilet:stoma = [yes|no] toilet:ostomy_irrigation = [yes|no] http://wiki.openstreetmap.org/wiki/Toilet -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subsequent wikipedia links
I made some changes to the page Key:wikipedia on the wiki. Please review: http://wiki.openstreetmap.org/w/index.php?title=Key%3Awikipediadiff=1060207oldid=1041603 2014-07-01 19:58 GMT-03:00 Jo winfi...@gmail.com: I've been experimenting with Wikidata a bit. I'm not a Wikipedian, rather a convinced Openstreetmapper. One of the problems I had with Wiktionary and Wikipedia is how data is duplicated over and over again. Wikidata finally started solving that. We should take advantage from that. Here are some examples of things I consider useful: Everything named after Guido Gezelle (mostly streets) http://overpass-turbo.eu/?Q=%28relation[%22name%3Aetymology%3Awikidata%22%3D%22Q336977%22]%3B%0A%3E%3E%3B%0A%3E%3B%0Away[%22name%3Aetymology%3Awikidata%22%3D%22Q336977%22]%3B%0A%3E%3B%0Anode[%22name%3Aetymology%3Awikidata%22%3D%22Q336977%22]%3B%29%3B%0Aout%20meta%3BC=51.98185;4.83689;7R Replace it with Q232785 and you get everything related to Father Damien. Unfortunately I didn't find where they buried his hands on Molokai. Polyglot 2014-07-02 0:22 GMT+02:00 Tobias Knerr o...@tobias-knerr.de: On 01.07.2014 22:25, yvecai wrote: This map could also be done with a third project linking OSM and Wikidata by automatically linking both datasets instead of manual tag entry of technical references. Call Overpass for OSM data (admin boundaries), then search wikimedia commons for flags with the corresponding name. But why would you prefer such a vague and error-prone style of linking when unambiguous linking via ID is possible? Even in very simple cases this is going to break down. Searching for flag Austria on Wikimedia Commons, for example, gives you the following top three hits: 1. http://commons.wikimedia.org/wiki/File:Animated-Flag-Austria.gif 2. http://commons.wikimedia.org/wiki/File:Flag_Austria_template.gif 3. http://commons.wikimedia.org/wiki/File:Smile-flag_Austria.gif The one we actually want is only ranked fourth: 4. http://commons.wikimedia.org/wiki/File:Flag_of_Austria.svg Wikidata, on the other hand, gets us straight to the one we want. How isn't this the better solution? ___ 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] Subsequent wikipedia links
2014-07-09 16:37 GMT+02:00 John Packer john.pack...@gmail.com: I made some changes to the page Key:wikipedia on the wiki. Please review: http://wiki.openstreetmap.org/w/index.php?title=Key%3Awikipediadiff=1060207oldid=1041603 your edit looks fine to me, besides that you removed the url reference. This is still a valid tagging method, isn't it? (Shouldn't be used for wikipedia, but is fine for the rest, and should IMHO be kept there as a reference). Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - Power transmission refinement - RFC 2
2014-07-09 15:40 GMT+02:00 Tod Fitch t...@fitchdesign.com: Which I, as a mapper more interested in roads and trails, ignore as I don't know what to put there and I'd rather have nothing than something that is wrong. You're absolutely right. JOSM ask for voltage to encourage users to look for it. If they don't know they'd rather ignore such warnings. And the power=line object will be left without voltage=* for a while and other mappers (like me) can complete it later. Many of the larger power lines (in a physical sense if not an electrical power sense) on large metal pylons are visible on satellite imagery, but their voltage isn't. So an arm chair mapper can show the location but not the voltage. Arm chair mappers can look on public grid maps. In France we can have such information on government's web pages. http://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/France#Cartes_RTE_.C3.A0_l.27.C3.A9chelle_r.C3.A9gionale When hiking or driving I can see the local power poles and sometimes guess if they carry power or communications cables or both. And I can see and make the distinction between a power line that is on large metal pylons and others. Since some of these items are really useful as navigation landmarks in undeveloped areas, I map them as I can. But that mapping will never include voltage, whether it is AC or DC, etc as I don't know and have no easy way to find out. The problem is the distinction you make. It won't be the same as your colleagues or neighbours. And no one in OSM will be aware of that. I don't have a clue to what the most power=minor_line objects correspond to exactly. One more thing : The proposal provides another definition for towers/poles. They're not used with voltage distinction any more. Then, if a line is carried by *heavy metal towers*, OSM will use *power=tower* + design=* and if it is carried by *small poles*, we'll have *power=pole* in the DB. All the best *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Subsequent wikipedia links
I removed the link to the key url=* because it's own wiki page advises it shouldn't be used, so I figured there was no need to link it here. As far as I understood, although it might make sense to tag an URL in some cases, the meaning of this key is too generic, making it hard to be used by tools. Therefore it's better to use another key that better indicates the meaning or relation of the URL, such as website=*, wikipedia=* and so on (not sure if there are others). 2014-07-09 11:43 GMT-03:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-07-09 16:37 GMT+02:00 John Packer john.pack...@gmail.com: I made some changes to the page Key:wikipedia on the wiki. Please review: http://wiki.openstreetmap.org/w/index.php?title=Key%3Awikipediadiff=1060207oldid=1041603 your edit looks fine to me, besides that you removed the url reference. This is still a valid tagging method, isn't it? (Shouldn't be used for wikipedia, but is fine for the rest, and should IMHO be kept there as a reference). Cheers, Martin ___ 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
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] 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] Subsequent wikipedia links
2014-07-09 16:57 GMT+02:00 John Packer john.pack...@gmail.com: I removed the link to the key url=* because it's own wiki page advises it shouldn't be used, so I figured there was no need to link it here. Thanks for pointing at this, I have amended this sentence to make more sense, please check: http://wiki.openstreetmap.org/w/index.php?title=Key%3Aurldiff=1060215oldid=997125 As far as I understood, although it might make sense to tag an URL in some cases, the meaning of this key is too generic, making it hard to be used by tools. Therefore it's better to use another key that better indicates the meaning or relation of the URL, such as website=*, wikipedia=* and so on (not sure if there are others). +1, where one of these more specific tags can be applied, it is better to use them, for the rest url will still remain a valid tag. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rendering change: buildings within highway areas
We get increasing feedbacks on my local list that the new rendering rule is counter-intuitive (to not say that it is considered as a bug). Now roads are rendered on top of buildings even when roads are really under buildings or underground (tunnels). Why not when your primary interest is for roads, but it's not so nice when your interest is buildings ;-) Examples: http://www.openstreetmap.org/#map=18/47.61190/-122.33067 http://www.openstreetmap.org/#map=19/43.28450/5.38016 This is now clearly a map style oriented for transport and the result is more abstractive than previously where the z order reflected more the real world. We can blame Google for many things but, at least, they render tunnels below the buildings... If you don't like buildings, than make it frankly and remove them completely from the style. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rendering change: buildings within highway areas
On 9 July 2014 16:29, Pieren pier...@gmail.com wrote: We get increasing feedbacks on my local list that the new rendering rule is counter-intuitive (to not say that it is considered as a bug). Now roads are rendered on top of buildings even when roads are really under buildings or underground (tunnels). Why not when your primary interest is for roads, but it's not so nice when your interest is buildings ;-) Examples: http://www.openstreetmap.org/#map=18/47.61190/-122.33067 http://www.openstreetmap.org/#map=19/43.28450/5.38016 This is now clearly a map style oriented for transport and the result is more abstractive than previously where the z order reflected more the real world. We can blame Google for many things but, at least, they render tunnels below the buildings... If you don't like buildings, than make it frankly and remove them completely from the style. Thank you for your feedback. It seems none of the solutions is really ideal. I think the old rendering was not perfect either. Here you can compare them: http://bl.ocks.org/tyrasd/raw/6164696/#16.00/43.2856/5.3814 Rendering order is still work in progress, so we might decide to move things around again later. Suggestions are welcome. -- Matthijs ___ 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] Rendering change: buildings within highway areas
Am 09.07.2014 17:29, schrieb Pieren: We get increasing feedbacks on my local list that the new rendering rule is counter-intuitive (to not say that it is considered as a bug). Now roads are rendered on top of buildings even when roads are really under buildings or underground (tunnels). Why not when your primary interest is for roads, but it's not so nice when your interest is buildings ;-) Examples: http://www.openstreetmap.org/#map=18/47.61190/-122.33067 http://www.openstreetmap.org/#map=19/43.28450/5.38016 This is now clearly a map style oriented for transport and the result is more abstractive than previously where the z order reflected more the real world. We can blame Google for many things but, at least, they render tunnels below the buildings... If you don't like buildings, than make it frankly and remove them completely from the style. +1 another problem is that building=roof is not rendered at all, anymore: https://www.openstreetmap.org/way/238468901#map=19/47.99558/7.84189 resulting in a new note: https://www.openstreetmap.org/note/195181 cu fly ___ 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] Rendering change: buildings within highway areas
MapQuest Open seems to have a good compromise in this case--the tunnel is rendered above the buildings, but is partly transparent (to allow the user to see other features) and has more prominent dashed casing (to indicate it is below-ground). On Wed, Jul 9, 2014 at 10:56 AM, Matthijs Melissen i...@matthijsmelissen.nl wrote: On 9 July 2014 16:29, Pieren pier...@gmail.com wrote: We get increasing feedbacks on my local list that the new rendering rule is counter-intuitive (to not say that it is considered as a bug). Now roads are rendered on top of buildings even when roads are really under buildings or underground (tunnels). Why not when your primary interest is for roads, but it's not so nice when your interest is buildings ;-) Examples: http://www.openstreetmap.org/#map=18/47.61190/-122.33067 http://www.openstreetmap.org/#map=19/43.28450/5.38016 This is now clearly a map style oriented for transport and the result is more abstractive than previously where the z order reflected more the real world. We can blame Google for many things but, at least, they render tunnels below the buildings... If you don't like buildings, than make it frankly and remove them completely from the style. Thank you for your feedback. It seems none of the solutions is really ideal. I think the old rendering was not perfect either. Here you can compare them: http://bl.ocks.org/tyrasd/raw/6164696/#16.00/43.2856/5.3814 Rendering order is still work in progress, so we might decide to move things around again later. Suggestions are welcome. -- Matthijs ___ 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] 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] 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] 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
Re: [Tagging] tree shrines
I suppose you were in contact with Lutz. Our policy is to render what's mapped and in that be quick to market. If there's a tagging found sufficiently often it is considered for inclusion in the historic map. The wiki page map features describes what kind of tagging is depicted in OUR map. It does not describe what some pseudo-official tagging proposal came up to. We gave up in waiting for tagging discussions coming to a final solution. Usually they tend to become endless discussions without a final consensus. And I definitely don't consider 10-20 positive votes for a successful proposal to be in any way representative for the community of tens of thousands of active mappers or more. However, when a proposal leads to another tagging being accepted by the community in a considerable way we are eager to include it on our map. Cheers, Zecke ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] RFC: Proposed Node Relation
I have proposed the node relation, a concept that I was missing for some time now. Have a look here: https://wiki.openstreetmap.org/wiki/Relations/Proposed/Node cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tree shrines
In the US, most of these sort of things are markers where people died in accidents. Wikipedia calls them roadside memorials ( https://en.wikipedia.org/wiki/Roadside_memorial), and I guess that might be the most common term in the US. Shrine, to my ears, has a different, more specifically religious connotation than these memorials--see the examples at https://en.wikipedia.org/wiki/Shrine I wouldn't use shrine to describe a marker where someone died unless it was a saint, or it was for people who literally worshiped ancestors. On Wed, Jul 9, 2014 at 7:02 AM, Friedrich Volkmann b...@volki.at wrote: Wayside shrines and crosses are quite common here in Austria, and probably in other parts of Europe too. They are mounted on posts (or pillars, walls...) made of various materials (wood, stone...), or on trees. When mounted on trees, I use a tag combination of historic=wayside_cross (or _shrine) with natural=tree + species=* etc. and (if applicable) name=*. I mapped a lot of these that way. Therefore I felt kind of annoyed when someone created a wiki page for the new and apparently synonymous tag historic=tree_shrine and immediately added it to the map features without any preceeding usage or discussion. I contacted him, but we didn't achieve a consensus. In order to untangle that tagging issue, I would like to ask native English speakers for their understanding of terms: - How do you call a cross at a tree? - How do you call a picture of a saint, or other shrine-like object, at a tree? - Is the term tree shrine common? - Is it considered a subset of the term wayside shrine, i.e. can you refer to a tree shrine as a wayside shrine? If we come to the conclusion that tree shrine is the correct term and that we therefore ought to tag them as historic=tree_shrine, some further questions arise: - Does it apply to crosses as well, or only to pictures and alike? - Does historic=tree_shrine imply natural=tree? - Is name=* the name of the tree or the name of the shrine/picture/cross? What if they differ? - Is start_date the birthdate of the tree or the date the shrine was made? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ 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] tree shrines
In the US, most of *these* sort of things are markers where people died in accidents. Wikipedia calls them roadside memorials ( https://en.wikipedia.org/wiki/Roadside_memorial), and I guess that might be the most common term in the US. To clarify, by these, you mean historic=wayside_cross, correct? Or does historic=tree_shrine has the same meaning? 2014-07-09 15:15 GMT-03:00 Brad Neuhauser brad.neuhau...@gmail.com: In the US, most of these sort of things are markers where people died in accidents. Wikipedia calls them roadside memorials ( https://en.wikipedia.org/wiki/Roadside_memorial), and I guess that might be the most common term in the US. Shrine, to my ears, has a different, more specifically religious connotation than these memorials--see the examples at https://en.wikipedia.org/wiki/Shrine I wouldn't use shrine to describe a marker where someone died unless it was a saint, or it was for people who literally worshiped ancestors. On Wed, Jul 9, 2014 at 7:02 AM, Friedrich Volkmann b...@volki.at wrote: Wayside shrines and crosses are quite common here in Austria, and probably in other parts of Europe too. They are mounted on posts (or pillars, walls...) made of various materials (wood, stone...), or on trees. When mounted on trees, I use a tag combination of historic=wayside_cross (or _shrine) with natural=tree + species=* etc. and (if applicable) name=*. I mapped a lot of these that way. Therefore I felt kind of annoyed when someone created a wiki page for the new and apparently synonymous tag historic=tree_shrine and immediately added it to the map features without any preceeding usage or discussion. I contacted him, but we didn't achieve a consensus. In order to untangle that tagging issue, I would like to ask native English speakers for their understanding of terms: - How do you call a cross at a tree? - How do you call a picture of a saint, or other shrine-like object, at a tree? - Is the term tree shrine common? - Is it considered a subset of the term wayside shrine, i.e. can you refer to a tree shrine as a wayside shrine? If we come to the conclusion that tree shrine is the correct term and that we therefore ought to tag them as historic=tree_shrine, some further questions arise: - Does it apply to crosses as well, or only to pictures and alike? - Does historic=tree_shrine imply natural=tree? - Is name=* the name of the tree or the name of the shrine/picture/cross? What if they differ? - Is start_date the birthdate of the tree or the date the shrine was made? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ 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 - Power transmission refinement - RFC 2
On 09/07/2014 09:44, Kytömaa Lauri wrote: Calling it replacement doesn't mean it's not deprecation. The proposal is still trying to deprecate power=minor_line, and to remove the simple physical distinction between really big thing on big pylons vs. smaller overhead lines that you can often find everywhere. Mappers can make that size distinction much easier and faster than they could estimate what the actual voltage happens to be; the size is the criteria, not the voltage, even if the size quite often exceeds the threshold after some value in any particular country. And that classification is the most prominent feature for everybody else not interested in the voltages or circuits or number of cables or whatever; in mostly incomplete areas, mappers are most likely to first draw only the big things, and only then start adding the minor_line's, so it's even easier to use the right choice. Pnorman provided you with nice example pictures for the distinction on the rendering github pages, and gravitystorm explained in detail in another issue in the same tracker why arbitrarily changing established tags is bad for the community. It should be a lesser inconvenience for power infrastructure consumers to select where (power=line or power=minor_line) and voltage= etc., than it would be for every other existing map to be cluttered with prominent power lines crisscrossing the suburbs and countryside until all eternity (entering a voltage=* tag can never be enforced on mappers). +1 I see two problems with this proposal. 1) This proposal requires a voltage tag to distinguish big and small power lines. If mappers don't add a voltage tag then it's probably because they don't know the voltage and this information is often difficult to get hand on. However, they can mostly figure out whether it is a major or a minor power line looking at the towers/poles and use either line or minor line appropriately. With only power=line as main tag and not knowing the voltage they can't add this information anymore. 2) The proposal will require renderers and other consumers to evaluate the voltage tag if they want to distinguish between major and minor lines. This can however be a rather complex task since the voltage tag values are not always simple numerical values as required to perform simple comparisons. In the case where two voltage separated by a semicolon are specified more complex processing using regular expressions etc is required. I have the feeling that the Carto stylesheet maintainers won't be eager to implement that (if supported by Carto at all). The result of deprecating minor_line will effectively be a loss of information in the database and in inferior rendering of power lines (400 kilovolt lines and 400 volt lines will be rendered the same way!) Ole ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Rendering for mappers
W dniu 09.07.2014 19:08, SomeoneElse napisał(a): 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 That is exactly what I would expect! There are few nice themed styles on the main page, but no such working map. It doesn't need to be ugly, but its functionality for mappers must come first. 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. MapQuest Open is the only map style I never truly understood - it's a general purpose map, while others have their purpose stated clear in the name. What were the reason behind taking it on board, does anybody know? OpenSeaMap or anything like this would better complete the set of maps we can use from the main page, this one is just duplicating the purpose of our default map. I have no preference which general map should be default - the beauty one or the working one - but two beauty maps and no working one makes no sense to me. When I act as an end-user of OSM, I want better search and additional services (routing is what I miss the most), not the nicer rendering. When I act as a mapper, I want to simply see all my tags. -- Mambałaga ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rendering for mappers
MapQuest Open is the only map style I never truly understood - it's a general purpose map, while others have their purpose stated clear in the name. What were the reason behind taking it on board, does anybody know? MapQuest matches the prerequisites to be a feature tile on OSM homepage [1]. About the rendering for the mappers: A similar discussion recently started on the *talk* mailing list [2]. [1]: http://wiki.openstreetmap.org/wiki/Featured_tiles [2]: https://lists.openstreetmap.org/pipermail/talk/2014-June/070074.html 2014-07-09 16:44 GMT-03:00 Daniel Koć dan...@xn--ko-wla.pl: W dniu 09.07.2014 19:08, SomeoneElse napisał(a): 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 That is exactly what I would expect! There are few nice themed styles on the main page, but no such working map. It doesn't need to be ugly, but its functionality for mappers must come first. 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. MapQuest Open is the only map style I never truly understood - it's a general purpose map, while others have their purpose stated clear in the name. What were the reason behind taking it on board, does anybody know? OpenSeaMap or anything like this would better complete the set of maps we can use from the main page, this one is just duplicating the purpose of our default map. I have no preference which general map should be default - the beauty one or the working one - but two beauty maps and no working one makes no sense to me. When I act as an end-user of OSM, I want better search and additional services (routing is what I miss the most), not the nicer rendering. When I act as a mapper, I want to simply see all my tags. -- 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] Rendering for mappers
W dniu 09.07.2014 22:03, John Packer napisał(a): MapQuest matches the prerequisites to be a feature tile on OSM homepage [1]. OpenSeaMap matches them even better, so it's still not clear to me why MQ was selected and OSeaM was not. A similar discussion recently started on the _talk_ mailing list [2]. Andy has just wrote that. OK, I stop off topic discussion and move with it to the right place. Thanks! -- Mambałaga ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tree shrines
On Wed, Jul 9, 2014 at 12:52 PM, John Packer john.pack...@gmail.com wrote: To clarify, by these, you mean historic=wayside_cross, correct? Or does historic=tree_shrine has the same meaning? I would suspect so - this is consistent with my area as well, where these features are called descansos (a Spanish word) and usually take the form of crosses in the freeway median/shoulder. The use of descanso is probably unusual in the non-Southwestern US, so I would concer with roadside_memorial as a tag for these. That said, I do not know how valuable it is to map them. They are a big part of the culture in this area and so tend to be both elaborate and permanent, but in other parts of the US where I have lived they were often simple and temporary, not useful features for navigation. Their usefulness likely varies significantly with culture. 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] Feature proposal - Power transmission refinement - RFC 2
On Wed, Jul 9, 2014 at 1:30 PM, Ole Nielsen on-...@xs4all.nl wrote: 1) This proposal requires a voltage tag to distinguish big and small power lines. If mappers don't add a voltage tag then it's probably because they don't know the voltage and this information is often difficult to get hand on. However, they can mostly figure out whether it is a major or a minor power line looking at the towers/poles and use either line or minor line appropriately. With only power=line as main tag and not knowing the voltage they can't add this information anymore. 2) The proposal will require renderers and other consumers to evaluate the voltage tag if they want to distinguish between major and minor lines. This can however be a rather complex task since the voltage tag values are not always simple numerical values as required to perform simple comparisons. In the case where two voltage separated by a semicolon are specified more complex processing using regular expressions etc is required. I have the feeling that the Carto stylesheet maintainers won't be eager to implement that (if supported by Carto at all). The result of deprecating minor_line will effectively be a loss of information in the database and in inferior rendering of power lines (400 kilovolt lines and 400 volt lines will be rendered the same way!) As an additional support for this perspective, in my area (where I am able to access detailed utility maps because they are publicly owned and the local authority is unusually thorough with its website), lines at 13.2kv and 115kv are visually indistinguishable, but a map renderer might be tempted to show them differently because they are distribution vs transmission levels. However, when the 115kv lines leave the city they go from wood poles to metal ones without an actual change in voltage. Further, at least in my experience this information is usually not at all easy to access in the US. In many areas determining voltages for transmission lines would probably require visits to the offices of multiple local planning authorities, photocopy fees, and in general a great deal of hassle. I absolutely support marking voltage (and also capacity if possible) because I find this to be interesting, but it shouldn't be the basis for rendering, as it does not reliably predict visual appearance (what is on the ground) and it is not easy to determine. 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] tree shrines
What Jesse said. :) Including that they're often relatively temporary. That might explain why there are so few in the US compared to Europe? I'd seen this discussion before and thought it was kind of obscure, then just looked at taginfo and was surprised by how many there are--wow! I'd seen many of these small shrines in Japan but didn't know it was such a big thing in Europe. 45K wayside_cross: http://taginfo.openstreetmap.org/tags/historic=wayside_cross#map 23K wayside_shrine: http://taginfo.openstreetmap.org/tags/historic=wayside_shrine#map On Wed, Jul 9, 2014 at 3:19 PM, Jesse Crawford je...@jbcrawford.us wrote: On Wed, Jul 9, 2014 at 12:52 PM, John Packer john.pack...@gmail.com wrote: To clarify, by these, you mean historic=wayside_cross, correct? Or does historic=tree_shrine has the same meaning? I would suspect so - this is consistent with my area as well, where these features are called descansos (a Spanish word) and usually take the form of crosses in the freeway median/shoulder. The use of descanso is probably unusual in the non-Southwestern US, so I would concer with roadside_memorial as a tag for these. That said, I do not know how valuable it is to map them. They are a big part of the culture in this area and so tend to be both elaborate and permanent, but in other parts of the US where I have lived they were often simple and temporary, not useful features for navigation. Their usefulness likely varies significantly with culture. 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 - Power transmission refinement - RFC 2
If really you insist to have an indication for minor, we can introduce line:type=minor/major but I definitely recommend to get this out of the primary tag. Ok ? *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rendering for mappers
I think the problem with Openseamap is that they have two layers of tiles, one standard layer which they take from openstreetmap servers: http://b.tile.openstreetmap.org/15/17484/10492.png and one over it, with all the symbols: http://tiles.openseamap.org/seamark/15/17484/10492.png 2014-07-09 22:15 GMT+02:00 Daniel Koć dan...@xn--ko-wla.pl: W dniu 09.07.2014 22:03, John Packer napisał(a): MapQuest matches the prerequisites to be a feature tile on OSM homepage [1]. OpenSeaMap matches them even better, so it's still not clear to me why MQ was selected and OSeaM was not. A similar discussion recently started on the _talk_ mailing list [2]. Andy has just wrote that. OK, I stop off topic discussion and move with it to the right place. Thanks! -- 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] RFC: Proposed Node Relation
Should there be a relation with type=way? For when you need a way that is not an area over an existing way. Example would be a fence that is put on a wall. Janko Dana 9. 7. 2014. 19:47 osoba Martin Koppenhoefer dieterdre...@gmail.com napisala je: I have proposed the node relation, a concept that I was missing for some time now. Have a look here: https://wiki.openstreetmap.org/wiki/Relations/Proposed/Node cheers, Martin ___ 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] RFC: Proposed Node Relation
Am 09/lug/2014 um 23:49 schrieb Janko Mihelić jan...@gmail.com: Should there be a relation with type=way? For when you need a way that is not an area over an existing way. Example would be a fence that is put on a wall. I think yes ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
