Re: [Tagging] Proposal - voting finished - man_made=lamp
2013/11/26 Manuel Hohmann mhohm...@physnet.uni-hamburg.de yes, rejected ;-) I'm really not sure what you don't understand about the word DRAW or about the fact that the total number of positive votes exceeds the total number of negative votes. I think it is pointless to continue discussing about a draw as the rules seem quite clearly to require a majority: A rule of thumb for enough support is *8 unanimous approval votes* or *15 total votes with a majority approval*, but other factors may also be considered (such as whether a feature is already in use). the fact that some of the tags you propose are already in use (differently to what you propose) doesn't strengthen the idea that this should be considered approved despite the strong opposition. there are also fixed lanterns, and there is even another use for it in architecture, probably you'll find it in this context as well (building:part etc.) Yes, there are indeed, I do not doubt that. It was just a general remark that this tag may also be misinterpreted (which probably applies to many words, one needs to choose carefully in any case). well, this is not an insurmountable hurdle, we should simply pay attention to how we precisely name those tags (e.g. the architectural element could be called roof_lantern). You could use man_made=pole / post / mast / tower /... for the support/structure (if mapped on a node). - - lantern (which I actually like more than the lamp:type=street_lamp in my proposal, since it takes the street out of this name, and would be a lighting for maybe a railway, an area... or a street) - - signal_lamp (yes, I checked the term - see wikipedia) - - warning (a hazard warning lamp) - - aviation (like those lights at an airport runway) these terms IMHO don't fit well under the same key, lantern is a type of light defined by the design/construction, while warning and aviation are defined by the scope. What about light_source? This is also not used so far, and it gives a rather accurate description of the object being mapped. Something ending in _type sounds more like a subclass to me (as we don't tag highway_type=*, but highway=track, tracktype=*). I would go for the established lamp_type as this is in use and has according values. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Proposal - voting finished - man_made=lamp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think it is pointless to continue discussing about a draw as the rules seem quite clearly to require a majority: A rule of thumb for enough support is *8 unanimous approval votes* or *15 total votes with a majority approval*, but other factors may also be considered (such as whether a feature is already in use). the fact that some of the tags you propose are already in use (differently to what you propose) doesn't strengthen the idea that this should be considered approved despite the strong opposition. Of course I have nowhere written that my proposal has been approved or that it should be considered approved - simply because it did not reach a majority, and there was enough criticism against it. But with with the same argument one can oppose the statement it would have been clearly rejected, since it also received about as much support as criticism. I fully agree with Dan S here: The vote indicates a maybe, but not in this exact form, and this is just what I meant by draw all the time. I don't see any reason to discuss this either, since a discussion does not alter anything here. well, this is not an insurmountable hurdle, we should simply pay attention to how we precisely name those tags (e.g. the architectural element could be called roof_lantern). Sure, I agree. these terms IMHO don't fit well under the same key, lantern is a type of light defined by the design/construction, while warning and aviation are defined by the scope. Those were just quick ideas / making up examples. One can probably find better names for these objects, following the principle of carefully choosing as mentioned above. I would go for the established lamp_type as this is in use and has according values. AFAIK lamp_type is rather used as a sub-tag to highway=street_lamp and specifies the type of lantern (gaslight, electric...). Using this on its own in the form lamp_type=lantern would hopelessly mix up those different uses. See http://taginfo.openstreetmap.org/keys/lamp_type#combinations for this. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSlcivAAoJEPvf9RrsekSykmcH/jqKrybkuqOAqYZJixn7E8gD yAcw6TlUlYPL9JI1jxmnSBpg2FepGjt/bof2TKdryORwSBdBivnTc++AC74brAs+ 7tXcQjpCGgXd6LL6f6yuPARGifXRFJ546bbU3aBKWwErjCf0V9ZByKw8p4ffIi9C iNXg+SKAU52GQZHTm7ByvQQXc8yfBEVER23mKSBq8g0Cb7fmYZaYSjN3o8MZTHjK AdywhcBXqqjOiveNl85JqlMd8N2K8hYEuVy/IDBQQlvYrNficsxhmF/Mmd4KT92G I1zdOved4jjeD7ECXlbYrAuBxAZCFW0td0SPk+uWHrw2OP6c+bsJOt4+MA3fwBs= =gllt -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal - voting finished - man_made=lamp
2013/11/27 Manuel Hohmann mhohm...@physnet.uni-hamburg.de I would go for the established lamp_type as this is in use and has according values. AFAIK lamp_type is rather used as a sub-tag to highway=street_lamp and specifies the type of lantern (gaslight, electric...). Using this on its own in the form lamp_type=lantern would hopelessly mix up those different uses. This was a misunderstanding, my suggestion was to use lamp_type for lamp types (in reply to your suggested light:source I was pointing out that there is a used tag) and light_type for the kind of device (lantern in this example). IMHO it would not be desirable to use different keys for the same property according to the kind of device (i.e. a lantern and a street_lamp should have the same subtag to map the lamp type / light source). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal - voting finished - man_made=lamp
Manuel Hohmann mhohm...@physnet.uni-hamburg.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A draw means rejected as it isn't a majority for yes. A partial yes like an abstain counts as vote that isn't yes, so for practical reasons you can count this like a no. At least this is what the rules had been so far. A draw is a draw, it's not a majority for no either. You can count an abstain whatever you want, it neither yes nor no. Here we had a partial yes. And besides, as I explained before, I also took into account the comments and reasons for opposing in the decision to keep working on the proposal. To make it clear, I am not in general against tagging lights and lamps (besides those that already get tagged), but I also do not think that all kind of light emitting objects have necessarily to go under one and the same tag. Generally substituting one tag by requiring two tags isn't desirable (IMHO). The tag highway=street_lamp is widely used and there is (IMHO) no reason to believe a street light/lamp isn't part of a highway. You can see it as one or the other and apparently there are not so few mappers who see it as a usable tag. Yes, this is the main outcome of the voting, as I said. And this will be taken into account in the further work on this proposal. The discussions here and in the forum have shown that both opinions exist - - regarding street lamps as part of the highway or not. Given that there is already a tag for the (supposedly) most required thing in this field to be tagged, why not invent a (or more) new tag(s) for what remains and you want to tag? Of course one can do this as well. My aim was to unify the tagging of these objects, since they all generate light. This idea is not new - think of public_transport=stop_position, for example. But of course one can have different opinions, as always in OSM. And when inventing a new tag, why not do it right (i.e. with the correct terminology)? Just as there are different words in German (Leuchte, Strahler, Scheinwerfer, Fluter as opposed to Lampe), there are also in English. I was using the term that was attested to me by native speakers to be most commonly used, and also understandable to others. Many people, especially non-native speakers, might not even know the term light fitting, even though it's correct UK English. Why not e.g. use a tag floodlights for certain typology of lights, or lantern for another? This is also possible, provided that one can easily distinguish these topologies. As a remark, lantern was also on my list, but as I figured out, it usually refers to portable light sources. As an analogy, we also do not use highway=street, street=primary because the way stuff went has brought us this distinction already in the main tag, and someone now trying to reinvent this wheel would most probably fail. Of course, highway=* is a key that already indicates some type of way or related feature, so one can immediately specify the type of feature in the value. highway=street, street=primary would thus make no sense. This is different for man_made=*, which does not give much information on the type of object. One could of course also think of not using man_made at all, and introduce light=floodlights etc. as a new primary tag, in order to group light sources with a more unified tagging. But honestly I have no idea whether this would be better or worse. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSlJ11AAoJEPvf9RrsekSyp6sIAJUD+bqj2t8h/Z2nZsO7mD1f TE/p4R8BuY5K0CN1vJvECS/gyfn4jD8g3vSHpJ3pQBDfEjncjr2o3zpZXtWD+bp+ WPfE1BXr9ZHqmMH9qqbYXsmPL3UWdFrugE2b3Ll7UhvLWLU0ZRG7NWi4Mm1atwUX Y1ia7ggiAv+qlg/lh2yreIXTjGyl3EY8EM56Xn2A76+DaM2vRNeuVbSFvgR2DJez C/4kpqEHVimiCsqCmlGnEjrC0642BkWuM/dghlgS4ZgFp4GY5vWTz/R0Bs5iJ3ee 7p+ZDMTlJ2mrKczL8BVuDDASZ167m8mTO1jC6ibFP0Ob39/Om6141iRHc+WblcQ= =Jw6I -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging In my personal experience, the same type of lamps used for street lighting are also used in many business and apartment parking lots, and even in the occasional back yard. -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness: only light can do that. Hate cannot drive out hate: only love can do that. Dr. Martin Luther King, Jr. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal - voting finished - man_made=lamp
2013/11/25 Manuel Hohmann mhohm...@physnet.uni-hamburg.de This means that by any traditional reading, the proposal has been rejected, even though you seem to avoid the word. I am not avoiding anything, I am simply stating facts. And as a matter of fact, there are 19 positive votes, 18 negative ones, and one partial approval. By any mathematical reading, 19 18. You are cheating here, the voting period finished at 23 November, and by the 14th of November all 18 no-votes had already been cast, leading with this apparently clear rejection to desinterest by other potential rejecters. You are now counting post-voting-votes on the yes side in order to obfuscate the actual result. This proposal was rejected according to our rules and I now set it to rejected in the wiki. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal - voting finished - man_made=lamp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You are cheating here, the voting period finished at 23 November, and by the 14th of November all 18 no-votes had already been cast, leading with this apparently clear rejection to desinterest by other potential rejecters. You are now counting post-voting-votes on the yes side in order to obfuscate the actual result. This proposal was rejected according to our rules and I now set it to rejected in the wiki. Just in case you did not get it the first time: - - The 14th of November does not have any relevance here - there is no counting of votes somewhere in the middle of voting. - - Everyone has been free to vote, no matter the current vote count. If someone does vote against the proposal, his vote cannot be counted. - - At the end of the voting period there were 18 yes, 18 no and one partial yes. If this in in any way a clear result, then it is a draw. - - Comments indicate that the dominant reason for opposing was deprecating highway=street_lamp, not the additional / new tags of the proposal. - - The positive votes, further comments and the fact that even after the official voting period someone handed in another positive vote indicate clear interest in this proposal, or at least into its continuing development. - - For the aforementioned reasons, this proposal is further being worked on. I therefore set it to proposed, and I did this for a reason. - - I am not obfuscating anything, I am stating facts, and these can be found in the wiki. I hope this is finally clarified. Your opposing vote has been counted, the reasons you have given were taken into account and have been commented on. If you would like to further contribute, feel free to reply to these comments, or make further suggestions, or feel free to create your own proposal. I will continue working on this one, and take into account any constructive criticism or other contributions, including the received comments during voting, from anyone who is interested in contributing. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSlIXpAAoJEPvf9RrsekSyYCAIAKSaBBbzpEpigBp2j8/8oCWj O8fIwV5p7eC8309rTMUj9C1T3v4gsjozxg80N2ZVzr/8vPyvMP22nfLni2+toAzo UUZ0p42MAkMxZwUMn3E79G5Jg2JFoIDKGaDgInfjKe1lp56dqpUjeHBXBuG+Ddym tUtOeIEp+9NfXzliSVSdwA5u/CDjFOAvGLnsbNepo6rH6cDrbGgm/G973vUTYhqL zjf2Ii3Q9DzrsQ4Av2YVLoGg72Vq2ihRb0TsNP0NE+6rLDZ/BE+d37JEiF0uxFrV 1QQQZmf8FhV8JWjaHW6z7PFSbiFo0aZDC49i3+QA3gmhrsidTXUB9dMQRQTsswM= =j6/j -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal - voting finished - man_made=lamp
On 26.11.2013 11:33, Martin Koppenhoefer wrote: This proposal was rejected according to our rules and I now set it to rejected in the wiki. The rules also state All suggestions should be taken into account before a proposal is approved or rejected. The author is trying to do just that. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal - voting finished - man_made=lamp
On Tue, Nov 26, 2013 at 12:44 PM, Dan S danstowell+...@gmail.com wrote: Where can I read the rules? I searched the wiki for voting tag proposals etc and couldn't find them. On the Proposed_features main page. But don't read it as hard-coded rules but more as recommendations. I don't like when people think that the wiki is the bible. But I also don't like people saying that the vote process should be completely ignored. Take it as a good opportunity to express verbally a maximum of feedbacks, opinions and arguments about tags in OSM. It's better than nothing. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal - voting finished - man_made=lamp
2013/11/26 Manuel Hohmann mhohm...@physnet.uni-hamburg.de - - At the end of the voting period there were 18 yes, 18 no and one partial yes. If this in in any way a clear result, then it is a draw. A draw means rejected as it isn't a majority for yes. A partial yes like an abstain counts as vote that isn't yes, so for practical reasons you can count this like a no. At least this is what the rules had been so far. To make it clear, I am not in general against tagging lights and lamps (besides those that already get tagged), but I also do not think that all kind of light emitting objects have necessarily to go under one and the same tag. Generally substituting one tag by requiring two tags isn't desirable (IMHO). The tag highway=street_lamp is widely used and there is (IMHO) no reason to believe a street light/lamp isn't part of a highway. You can see it as one or the other and apparently there are not so few mappers who see it as a usable tag. Given that there is already a tag for the (supposedly) most required thing in this field to be tagged, why not invent a (or more) new tag(s) for what remains and you want to tag? And when inventing a new tag, why not do it right (i.e. with the correct terminology)? Just as there are different words in German (Leuchte, Strahler, Scheinwerfer, Fluter as opposed to Lampe), there are also in English. Why not e.g. use a tag floodlights for certain typology of lights, or lantern for another? As an analogy, we also do not use highway=street, street=primary because the way stuff went has brought us this distinction already in the main tag, and someone now trying to reinvent this wheel would most probably fail. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal - voting finished - man_made=lamp
2013/11/26 Pieren pier...@gmail.com: On Tue, Nov 26, 2013 at 12:44 PM, Dan S danstowell+...@gmail.com wrote: Where can I read the rules? I searched the wiki for voting tag proposals etc and couldn't find them. On the Proposed_features main page. Thanks. But don't read it as hard-coded rules but more as recommendations. I don't like when people think that the wiki is the bible. But I also don't like people saying that the vote process should be completely ignored. Take it as a good opportunity to express verbally a maximum of feedbacks, opinions and arguments about tags in OSM. It's better than nothing. I agree strongly. In this case, with an almost perfectly inconclusive result, I would say it is unfair to stamp the proposal as rejected since there was not a majority no-vote; but equally wrong to stamp it as sort-of-accepted (these are the two main positions in this thread so far!). The message from the voters is clear: maybe, but not in this exact form. Maybe the authors of the proposal will refine it to a stronger proposal, or maybe they won't. But it seems to me that some informal evolution is the next thing to consider, rather than repeated rounds of hyper-formalised proposing and voting. Dan ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal - voting finished - man_made=lamp
2013/11/26 Dan S danstowell+...@gmail.com I agree strongly. In this case, with an almost perfectly inconclusive result, I would say it is unfair to stamp the proposal as rejected since there was not a majority no-vote; actually this is how things are (and were) done nonetheless. There are lots of proposals that got rejected with zero no-votes, just because they hadn't gotten enough yes votes. The rules state that you need an absolute majority of yes for the approval. If a proposal gets rejected in a voting, this doesn't mean you cannot repropose it (indeed this is what is done here for the second time). but equally wrong to stamp it as sort-of-accepted (these are the two main positions in this thread so far!). The message from the voters is clear: maybe, but not in this exact form. +1, usually if there are a lot of no-votes there is something wrong, even if there is a majority of yes-votes. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal - voting finished - man_made=lamp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A draw means rejected as it isn't a majority for yes. A partial yes like an abstain counts as vote that isn't yes, so for practical reasons you can count this like a no. At least this is what the rules had been so far. A draw is a draw, it's not a majority for no either. You can count an abstain whatever you want, it neither yes nor no. Here we had a partial yes. And besides, as I explained before, I also took into account the comments and reasons for opposing in the decision to keep working on the proposal. To make it clear, I am not in general against tagging lights and lamps (besides those that already get tagged), but I also do not think that all kind of light emitting objects have necessarily to go under one and the same tag. Generally substituting one tag by requiring two tags isn't desirable (IMHO). The tag highway=street_lamp is widely used and there is (IMHO) no reason to believe a street light/lamp isn't part of a highway. You can see it as one or the other and apparently there are not so few mappers who see it as a usable tag. Yes, this is the main outcome of the voting, as I said. And this will be taken into account in the further work on this proposal. The discussions here and in the forum have shown that both opinions exist - - regarding street lamps as part of the highway or not. Given that there is already a tag for the (supposedly) most required thing in this field to be tagged, why not invent a (or more) new tag(s) for what remains and you want to tag? Of course one can do this as well. My aim was to unify the tagging of these objects, since they all generate light. This idea is not new - think of public_transport=stop_position, for example. But of course one can have different opinions, as always in OSM. And when inventing a new tag, why not do it right (i.e. with the correct terminology)? Just as there are different words in German (Leuchte, Strahler, Scheinwerfer, Fluter as opposed to Lampe), there are also in English. I was using the term that was attested to me by native speakers to be most commonly used, and also understandable to others. Many people, especially non-native speakers, might not even know the term light fitting, even though it's correct UK English. Why not e.g. use a tag floodlights for certain typology of lights, or lantern for another? This is also possible, provided that one can easily distinguish these topologies. As a remark, lantern was also on my list, but as I figured out, it usually refers to portable light sources. As an analogy, we also do not use highway=street, street=primary because the way stuff went has brought us this distinction already in the main tag, and someone now trying to reinvent this wheel would most probably fail. Of course, highway=* is a key that already indicates some type of way or related feature, so one can immediately specify the type of feature in the value. highway=street, street=primary would thus make no sense. This is different for man_made=*, which does not give much information on the type of object. One could of course also think of not using man_made at all, and introduce light=floodlights etc. as a new primary tag, in order to group light sources with a more unified tagging. But honestly I have no idea whether this would be better or worse. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSlJ11AAoJEPvf9RrsekSyp6sIAJUD+bqj2t8h/Z2nZsO7mD1f TE/p4R8BuY5K0CN1vJvECS/gyfn4jD8g3vSHpJ3pQBDfEjncjr2o3zpZXtWD+bp+ WPfE1BXr9ZHqmMH9qqbYXsmPL3UWdFrugE2b3Ll7UhvLWLU0ZRG7NWi4Mm1atwUX Y1ia7ggiAv+qlg/lh2yreIXTjGyl3EY8EM56Xn2A76+DaM2vRNeuVbSFvgR2DJez C/4kpqEHVimiCsqCmlGnEjrC0642BkWuM/dghlgS4ZgFp4GY5vWTz/R0Bs5iJ3ee 7p+ZDMTlJ2mrKczL8BVuDDASZ167m8mTO1jC6ibFP0Ob39/Om6141iRHc+WblcQ= =Jw6I -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal - voting finished - man_made=lamp
2013/11/26 Manuel Hohmann mhohm...@physnet.uni-hamburg.de A draw means rejected as it isn't a majority for yes. A draw is a draw, it's not a majority for no either. yes, rejected ;-) My aim was to unify the tagging of these objects, since they all generate light. This idea is not new - think of public_transport=stop_position, for example. a good example where it didn't work either: there are 1.2M of highway=bus_stop but only 200K public_transport platform and stop_position. Why not e.g. use a tag floodlights for certain typology of lights, or lantern for another? This is also possible, provided that one can easily distinguish these topologies. As a remark, lantern was also on my list, but as I figured out, it usually refers to portable light sources. there are also fixed lanterns, and there is even another use for it in architecture, probably you'll find it in this context as well (building:part etc.) fixed lantern: http://en.wikipedia.org/wiki/File:Lanterna_cafoscari.jpg architecture: http://en.wikipedia.org/wiki/File:Laternebap.jpg One could of course also think of not using man_made at all, and introduce light=floodlights etc. as a new primary tag, in order to group light sources with a more unified tagging. But honestly I have no idea whether this would be better or worse. You could use man_made=pole / post / mast / tower /... for the support/structure (if mapped on a node). What would be other values for this new key? Checked it, actually light is taken: http://taginfo.openstreetmap.org/keys/light#values but light_type seems available (zero usage as of taginfo). There is 337 of security:light_type which supports the idea that light_type is about the type of lightning device http://taginfo.openstreetmap.org/keys/security%3Alight_type and also the lamp_types support this reading: http://taginfo.openstreetmap.org/keys/lamp_type (they do not refer to the fixture). cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal - voting finished - man_made=lamp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yes, rejected ;-) I'm really not sure what you don't understand about the word DRAW or about the fact that the total number of positive votes exceeds the total number of negative votes. But another fact is that your opinion does not alter any of these facts. a good example where it didn't work either: there are 1.2M of highway=bus_stop but only 200K public_transport platform and stop_position. I wouldn't call an approved proposal, which hat 200K applications so far (the same order of magnitude as highway=street_lamp), not working. there are also fixed lanterns, and there is even another use for it in architecture, probably you'll find it in this context as well (building:part etc.) Yes, there are indeed, I do not doubt that. It was just a general remark that this tag may also be misinterpreted (which probably applies to many words, one needs to choose carefully in any case). You could use man_made=pole / post / mast / tower /... for the support/structure (if mapped on a node). Sounds reasonable to me, but also raises the question: If something is tagged as man_made=pole + light=* or the like, and there are additional tags, what do these tags apply to? This is the same problem as with tagging tourism=hotel, amenity=restaurant, and then something like wheelchair=yes all on one node - to which does the latter apply? In this example one can usually separate the hotel and the restaurant, but for a street lamp, one would probably want to attribute the pole and the light source to the same node, as they belong to a common structure. What would be other values for this new key? I guess that would be things that I placed under lamp:type in my proposal. For example, just some quick ideas: - - lantern (which I actually like more than the lamp:type=street_lamp in my proposal, since it takes the street out of this name, and would be a lighting for maybe a railway, an area... or a street) - - signal_lamp (yes, I checked the term - see wikipedia) - - warning (a hazard warning lamp) - - aviation (like those lights at an airport runway) Checked it, actually light is taken: http://taginfo.openstreetmap.org/keys/light#values but light_type seems available (zero usage as of taginfo). What about light_source? This is also not used so far, and it gives a rather accurate description of the object being mapped. Something ending in _type sounds more like a subclass to me (as we don't tag highway_type=*, but highway=track, tracktype=*). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSlL60AAoJEPvf9RrsekSyzZkH+wXC5f2QVbnnGj0rtW3iG3w2 NA0GpIrwmkAGtTtHCx9/wrp/ePzps6jdpAyzxSX+TosCMgeneXEKIAM6RmOx1XBa BD2PKmhWFnzJG33FGAIWv0vED2J1d250Iz22aG1zIELhlFlwzCxHnWtGUcslf9mD pxYT8uzlzAJLWfJLuhWgKkl0LEtm4qGzIQU88Turqjp84GjLxoygcw1UjB9asK+Z /SJv6ZInAo6X4VZEJV7iHwHqQWQDHETicXClJkgH3LJz6TDNdWE+ME3HRl3YrBdg at6PyW/3Mn+jMuY9TYLVVc7VqfSsT5+2K5Nb7/x1rVVYttVE19HALS5l816sw3A= =nFWp -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal - voting finished - man_made=lamp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 11/24/2013 09:45 AM, Manuel Hohmann wrote: In the two voting periods that this proposal has run through the following results have been obtained: - First voting period: 6 times yes. - Second voting period: 18 times yes, 18 times no, 1 partial approve. This means that by any traditional reading, the proposal has been rejected, even though you seem to avoid the word. This result therefore suggests the following possibilities for proceeding with this proposal: - Those who voted against the proposal need to agree on how to change it such that it will become more acceptable. I don't see why the onus should be on those who voted against the proposal. I could also say that those who voted for the proposal need to work on it to make it more acceptable. - Use the proposed features as they are. Yes, anyone is free to use any features, proposed or not, rejected or not. For this reason the status has for now been reset to proposed, until there is further progress. That's a great idea, we simply get rid of the rejected status and anything that is not accepted remains in proposed forever ;) Of course this opens the question - what if someone wanted to propose a *different* tagging of lamps, should they then overwrite the page with their proposal or should we simply have a ton of proposals in parallel? Bye Frederik - -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSkwTzAAoJEOx/uhGAJu9Hf1oH/A1qEcYczVXITa1MVJXJaUhL K8iPkjDtwnFlRDy3KpDXQaaPkyuzkFgb8IPCQXfvoyKQFm+lhRHD2xCnonlghrOG DMWtnlyB9AaJEbEBMD8NOQB7bwj8Uytndq5Bv9bAeMhS9DIPwcNl7W3d7BQgp0lH hqGgFE//k+vNRPV0d6A+SLsy+h2XOgu2uP7SI1zQYGjlK1F+ESRefuRr15OXt5nH nlmeIhFHb9zlMWahfE1gp3Jw8zyhzua+wGnVkEnWNeeLAnOQ8wdGWRt4YCNHO/TM JI45HqiX0hH3IFoPRDQva0efpDsvaQ51wQ2YjVljoRcI4T5qh1eDBBEeCwjd6kQ= =RtJ4 -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal - voting finished - man_made=lamp
2013/11/24 Manuel Hohmann mhohm...@physnet.uni-hamburg.de voting for the proposed man_made=lamp has been finished. The result and further proceeding can be found here: https://wiki.openstreetmap.org/wiki/Proposed_features/lamp#Results To summarize the results: In the two voting periods that this proposal has run through the following results have been obtained: - - First voting period: 6 times yes. - - Second voting period: 18 times yes, 18 times no, 1 partial approve. i.e. the proposal has been rejected. The reasons for opposing the proposal can be summarized as follows: - - Replacement / deprecation of the widely used highway=street_lamp. - - Introduction of new tags for a more complicated tagging. - - Introduction of tags which are not differentiated between light fixture, lamp and light. the question for the last point was not, whether this should all be tagged with different tags, but that you apparently want to map light fixtures and have chosen the wrong word for it (lamp). The reasons for approving the proposal can be summarized as follows: - - Deprecation of highway=street_lamp, since a lamp ultimately is not a highway or a part thereof. -1, not all lights are part of highways, but there are lights on highways and they can well be seen as part of the highway (it depends on your interpretation, but IMHO there are more arguments to see them as part of the road than not, see for instance the tag lit=yes. Those lights wouldn't be there if there was no highway). I am also not sure if it is a problem to have more than one tag for a kind of light, e.g. one for street lights and one or more for other kind of lights. Deprecating a highly used tag is almost never working. - - Introduction of new tags that allow a more detailed mapping of lamps. - - Introduction of new tags for light sources which are not street lamps. maybe you should focus on these without trying to deprecate other tags. There is no need to. - - Those who voted against the proposal need to agree on how to change it such that it will become more acceptable. they could (and here I am), but they do not need to. It is up to who wants change to convince the rest, not the other way round. - - Use the proposed features as they are. you can always do that, but your proceeding doesn't look very logical then: usually you start a proposal and voting in order to find problems with the suggested tags, and if a proposal voting doesn't show a good majority it usually indicates that it was either poorly drafted or has some other serious problems e.g. with the proposed tags. In this case I wouldn't continue using these tags as if nothing happened. Further, it is likely to happen anyway, since the result has shown that there is a clear interest in detailed lamp mapping from parts of the community. lamp mapping or lights mapping? The proposed tagging will evolve further through practical tag usage. I don't understand this, could you explain? For this reason the status has for now been reset to proposed, until there is further progress. IMHO you should start a new proposal and set the current one to rejected, because that's what it is. Two times actually. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal - voting finished - man_made=lamp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This means that by any traditional reading, the proposal has been rejected, even though you seem to avoid the word. I am not avoiding anything, I am simply stating facts. And as a matter of fact, there are 19 positive votes, 18 negative ones, and one partial approval. By any mathematical reading, 19 18. I don't see why the onus should be on those who voted against the proposal. I could also say that those who voted for the proposal need to work on it to make it more acceptable. For those who voted for the proposal it is already acceptable. But exactly as I stated before, the desires of the those opposing the proposal go in opposite directions, and since a proposal cannot be changed in both suggested directions simultaneously, this needs to be clarified. And this can only be done by those who have an actual desire which contradicts the proposal in its current form. That's a great idea, we simply get rid of the rejected status and anything that is not accepted remains in proposed forever ;) This is not a discussion about the rejected status in general. If there is a majority against a proposal and the creator buries it, of course he can do so. But if there are 1. 50% positive votes and 2. those who opposed the proposal indicate in their comments, that the reason for this was the single aspect of deprecating a high-use tag, there is more than enough justification to continue working on the proposal. Of course this opens the question - what if someone wanted to propose a *different* tagging of lamps, should they then overwrite the page with their proposal or should we simply have a ton of proposals in parallel? Of course anyone is free to propose whatever he wants to, including a different tagging of lamps, or to work on and improve an existing proposal. So am I. i.e. the proposal has been rejected. As stated above, there are more positive than negative votes. the question for the last point was not, whether this should all be tagged with different tags, but that you apparently want to map light fixtures and have chosen the wrong word for it (lamp). This is your opinion, but not even native speakers share this opinion. Let me remind you that the current tag is street_lamp, not street_light, and one may ask for the reason for this outcome. they could (and here I am), but they do not need to. It is up to who wants change to convince the rest, not the other way round. I have no intention to convince anyone to do anything. My intention is and always has been to propose a new tagging scheme, in other words, to develop such a scheme and to offer it to mappers who wish to use it. Who decides to use it and who decides not to use it is beyond my intention. you can always do that, but your proceeding doesn't look very logical then: usually you start a proposal and voting in order to find problems with the suggested tags, and if a proposal voting doesn't show a good majority it usually indicates that it was either poorly drafted or has some other serious problems e.g. with the proposed tags. In this case I wouldn't continue using these tags as if nothing happened. This is exactly what I have done. There has been a long discussion about these tags in the OSM forum, many suggestions have been made and included into the proposal, and as many positive comments from the same forum discussion indicate, they have lead to significant improvements of the proposal. Getting opinions on this proposed tagging, improving it and making it visible to the community, who can then use it or not, was my motivation for creating a proposal. Besides, I have nowhere indicated that I would proceed as if nothing happened. lamp mapping or lights mapping? Whatever you want to call them. I don't understand this, could you explain? No. But as a hint, tagging practice by a large number of mappers has usually more influence on tag usages than the status of proposals. IMHO you should start a new proposal and set the current one to rejected, because that's what it is. Two times actually. If you read carefully, you will find that the first voting was not even completed, but interrupted by myself after receiving 6 positive votes in the first two days. The reason was that there were some suggested improvements that I included into the proposal. And as I already stated before, the second voting received 50% of positive votes. And again, as I wrote before, comments indicate that for most people the only reason to oppose was the deprecation of a high-use tag, and this (and again further positive comments in the forum) justifies continued work on this proposal. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSk7n9AAoJEPvf9RrsekSyvd4H/j62YFJvg1/6VK+UAfQnNBW7 wSVNdnIMD08Vp3mIFLNl8+psLzmOW45UcNffYmAIpGSiwWnt3jeuW+PykEjTFY74
[Tagging] Proposal - voting finished - man_made=lamp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, voting for the proposed man_made=lamp has been finished. The result and further proceeding can be found here: https://wiki.openstreetmap.org/wiki/Proposed_features/lamp#Results To summarize the results: In the two voting periods that this proposal has run through the following results have been obtained: - - First voting period: 6 times yes. - - Second voting period: 18 times yes, 18 times no, 1 partial approve. The reasons for opposing the proposal can be summarized as follows: - - Replacement / deprecation of the widely used highway=street_lamp. - - Introduction of new tags for a more complicated tagging. - - Introduction of tags which are not differentiated between light fixture, lamp and light. The reasons for approving the proposal can be summarized as follows: - - Deprecation of highway=street_lamp, since a lamp ultimately is not a highway or a part thereof. - - Introduction of new tags that allow a more detailed mapping of lamps. - - Introduction of new tags for light sources which are not street lamps. Obviously the proposal cannot be changed in such a way to accommodate these different desires, as they directly contradict each other (in favour of / against deprecation of highway=street_lamp, make the proposed tagging simpler / more differentiated and introduce even more complicated tags). This result therefore suggests the following possibilities for proceeding with this proposal: - - Those who voted against the proposal need to agree on how to change it such that it will become more acceptable. This step requires further discussion and finally a conclusion, since obviously the proposal cannot be changed simultaneously in the different directions which have been suggested during voting. - - Use the proposed features as they are. Since the comments from the voting indicate that also among those who opposed the proposal there is agreement with some of its parts, this appears reasonable. Further, it is likely to happen anyway, since the result has shown that there is a clear interest in detailed lamp mapping from parts of the community. The proposed tagging will evolve further through practical tag usage. For this reason the status has for now been reset to proposed, until there is further progress. Best, Manuel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSkbybAAoJEPvf9RrsekSyFIUH+gNiZmD0SoR5HnDKtzQxFLvb zoYjjeKhNGU/CKFY/I+xY0BYTSe2pMjE7Qp+Gu0eN1UgUm+T2qF2awKYtOhnklYV 6DZvls5EnUtQ1q0MSW4VeZDjYPvhRjZO2aoIFed7iPIZfrdAzqfq6a6ij/njjLSz FOBVFhVO8wgP57lOIhZJ3Hb4SLtmdwB/pYaVtJ/nlcQL/Vs4FG9ohxFzTQe+effc a7KP6h8mqNX7M10VkRNjJnoTIzsdVKwhiWNl4qGbjIdxw86GcXWb3Y1AXdyiFQRl AgiKwoLsY1hANkAJtRCxbCC65s58ywN1gPDnjC37yqWa4pIoFa2/LoY8/2KSAyo= =15/T -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
