Re: [Tagging] square_paving_stones:width
On 11.03.2015 17:18, Mateusz Konieczny wrote: As described in paving_stones:n thread there is a problem with surface=paving_stones:integer values. To offer better alternative for storing information about size of square paving stones I am proposing this tag. What about rectangular paving stones? A key paving_stones:length (with a definition like the length the longest horizontal edge) would be more universal. And there should be some default unit (m?). -- 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] Current status of the key smoothness=*
There is clearly problem with verifiability of this tag, as in my case I am frequently unsure which value should be used. And it is not even starting to cover problems with multiple people having different opinions. It is not changing fact that there is no better tag to describe surface that is made of asphalt but of terrible quality. 2015-03-11 12:56 GMT+01:00 jgpacker john.pack...@gmail.com: Hi, I saw in the wiki page Key:smoothness http://wiki.openstreetmap.org/wiki/Key:smoothness#Controversy that there is a section about the controversy over it's verifiability. As far as I remember, this tag was throughly discussed here until a consensus was achieved (which was that it should be classified according to how usable the road is/which kinds of modes of transportation can use it). Is this claim over it's verifiability still current? I think it's not, and that this claim should be removed from the page (though it may be useful to write a section with a brief history of this key). Cheers, John -- View this message in context: http://gis.19327.n5.nabble.com/Current-status-of-the-key-smoothness-tp5836692.html Sent from the Tagging mailing list archive at Nabble.com. ___ 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] [Talk-bf] Buildings blocks
Am 11.03.2015 um 14:59 schrieb Jean-Marc Liotier j...@liotier.org: I object to admin_level=10 since http://wiki.openstreetmap.org/wiki/Tag:admin_level%3D10#11_admin_level_values_for_specific_countries most often uses that for place=neighbourhood but apart from that it looks very similar to what we want to model. I would rather chose admin_level=11 which is not documented - though it has 4355 occurrences I'd only use admin_level if this is really an administrative entity. place and admin are orthogonal. Place=plot is fine if these are really one plot, otherwise I'd go for place=block or city_block (the latter will look a bit silly in villages and hamlets) cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Talk-bf] Buildings blocks
On 11/03/2015 17:29, Martin Koppenhoefer wrote: Am 11.03.2015 um 14:59 schrieb Jean-Marc Liotier j...@liotier.org: I'd only use admin_level if this is really an administrative entity. place and admin are orthogonal. Yes, thanks for reminding that - let's keep admin_level out of the way of this discussion. Place=plot is fine if these are really one plot, otherwise I'd go for place=block or city_block Sounds reasonnable to me: place=city_block and/or place=neighborhood (as I guess there may be cases where a city block is larger than a neighborhood - so let's not force an unnecessary hierarchy) and then at the lowest level the place=plot. To people from francophone West Africa who might read this thread, the French translation for 'lot' is 'parcelle' - which may or may not be superposed to its administrative cousin, the 'parcelle cadastrale' which is the basis for the calculation of municipal taxes. ([city_block] will look a bit silly in villages and hamlets) I thought about that - but then I found that while a block is a synonym for a city block, it is also an administrative division of some South Asian countries: https://en.wikipedia.org/wiki/Block_%28district_subdivision%29 Wow - looks like we are going to settle the place=block vs. place=city_block discussion too... Also, https://en.wikipedia.org/wiki/City_block says the block is divided into lots and https://en.wikipedia.org/wiki/Land_lot says that 'lot' and 'plot' are synonymous... So, well - it all seems to hold together nicely. Or maybe I have a bad case of confirmation bias... ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Survey points
On 11/03/2015 14:43, moltonel 3x Combo wrote: Adding a separate survey_point node would have little benefit. The problem in many cases is the man_made key. I come across many objects that were tagged man_made=lighthouse, with other tags describing attributes of that structure, but then another mapper has come along and added the man_made=survey_point tag, that replaces the original tag. Often URL and other reference tags get overwritten as well. This is why I am of the view that survey points should be mapped on separate nodes. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
I fully agree with Martin. Availability of a tag like this is very important. I have to be able to enter a value while I am driving without sophisticated measuring equipment. I rather have a rating that is one step off on the scale than no rating at all. Many of these roads are in areas where few mappers do site surveys (I think of the roads we drove in Kenya), so any input is welcome even if it isn't perfect. We ran into some nasty surprises during our trip because the road quality wasn't tagged at all. Perhaps we can extend the library of pictures in the wiki to give people a better feeling which rating means what. Again: better an imperfect tag than no tag at all. On Wed, Mar 11, 2015 at 5:05 PM Mateusz Konieczny matkoni...@gmail.com wrote: There is clearly problem with verifiability of this tag, as in my case I am frequently unsure which value should be used. And it is not even starting to cover problems with multiple people having different opinions. It is not changing fact that there is no better tag to describe surface that is made of asphalt but of terrible quality. 2015-03-11 12:56 GMT+01:00 jgpacker john.pack...@gmail.com: Hi, I saw in the wiki page Key:smoothness http://wiki.openstreetmap.org/wiki/Key:smoothness#Controversy that there is a section about the controversy over it's verifiability. As far as I remember, this tag was throughly discussed here until a consensus was achieved (which was that it should be classified according to how usable the road is/which kinds of modes of transportation can use it). Is this claim over it's verifiability still current? I think it's not, and that this claim should be removed from the page (though it may be useful to write a section with a brief history of this key). Cheers, John -- View this message in context: http://gis.19327.n5.nabble.com/Current-status-of-the-key-smoothness-tp5836692.html Sent from the Tagging mailing list archive at Nabble.com. ___ 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] Leaf type of palm for leaf_type
It's all driven by technocrats who have no clue about what a tree or forest looks like in the real world. Small note, phrases like this are unlikely to be a good idea. 2015-03-11 17:36 GMT+01:00 Friedrich Volkmann b...@volki.at: On 10.03.2015 21:41, Bryce Nesbitt wrote: I'm seeking comments on adding palm to the leaf types at http://wiki.openstreetmap.org/wiki/Key:leaf_type A rendering engine can equate palm and broadleaved. Mappers are mapping palms very frequently, and having this key name I think would reduce confusion. I am glad you added a palm symbol to http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree#Possible_Rendering. When I created the conversion table in that section, I wondered why there is no palm symbol. I believed that I had already seen a palm symbol somewhere in the wiki, but I didn't manage to retrieve it. Then I searched google for palm symbols, but did not find anything either. So I was finally in doubt whether palm symbols are in use in carthography at all, although I still believe that palm symbols add value to maps. If broad and needle leaved trees get different symbols, palms should get their symbol as well because of their distinctive look. And - but that's just my subjective opinion - palm symbols look so cute that a map becomes more appealing when it incorporates them. Concerning tagging, there has been an approved and widely used key for a long time with exactly the values we need to distinguish palms, needle leaved and broad leaved trees. This key is type=*. This key worked quite well. However, there were two aesthetic issues with that key: That it is also used for relation types, and that there's a different key wood=* used for areas (natural=wood, landuse=forest). These issues evaporate when you look at them from an analytical perspective. type=* of trees never collides with type=* of relations, because trees are not relations. And wood=* has just another purpose. While type=broad_leaved/coniferous/palm defines the *habitus* of a single plant, wood=* describes a *behaviour* of an area. wood=evergreen means that assimilation (photosynthesis) does not change much with the seasons, and that the tree crowns remain continuously opaque. wood=coniferous means that the crowns are constantly semi-opaque, and that assimilation remains also at an intermediate level. wood=deciduous means that both assimilation and opaqueness have big seasonal amplitudes. This tag has enourmous ecological and econimical implications, and it may also be used to determine good times for documention (photographing, creating arial images) and recreational use. It is absolutely useless to use tags the other way round, i.e. plant habitus for forests or assimilation amplitudes for single trees. Therefore, no serious efforts were made to unify these tags, for many years. Then came Rudolf's surprise attack. He created a flawed proposal that missed all of the above points, and pushed it to voting just 3 weeks later. This was a much too short disussion period for a change affecting tremendous amounts of existing data. Many people, including me, did not have enough spare time in that time frame to participate in the discussion and to single out all of the flaws which include: - The wrong interpretation of the rule that type=* for non-relation elements should be avoided. - The mistaken reduction of wood=* to describe the type of leaves. - The wrong assumption that all of these tags mean the same. - The wrong assumption that new keys make things easier. Obviously, the opposite is true, because mappers and applications now need to know the new tags *in addition* to the conventional tags. - An ugly key name leaf_type=* although the more sound foliage=* key had been suggested on Talk:Key:wood as early as in 2012 by Alv. - broadleaved and needleleaved with no underscores - information loss due to the missing equivalent to type=palm - and worst of all, the deprecating established keys thing. There were more than 1 million of uses for wood=* and type=*. How can a proposal deprecate tags used a million times? Do 27 votes on a wiki page legitimate for the deprecation of tags used by 1 distinct mappers on 100 objects? Well, you could think that a proposal is one thing, and actual usage is another thing. Let's see how real mappers will accept it in real life. But in this very case, real world mappers got no chance. Immediately after voting has ended, Rudolf marked type=* and wood=* as deprecated on the natural=tree and wood=* wiki pages. I guess that some JOSM developers wanted to keep their editor cutting-edge by changing templates or suchlike to the new tagging scheme. And some validators spit out warnings when they come across the decprecated tags. As we all now, some sofa mappers spend all day searching for things to correct, using validators. These people do not care about how map features represent the real
Re: [Tagging] [Talk-bf] Buildings blocks
Hi Jean-Marc, Thank you for your detailed input and review on this idea. It indeed looks to fit well within the existing scheme as a more refined urban territorial subdivision. place = city/town suburb neighbourhood city_block/block / plot The trouble is there is no definition yet of city_block/block / plot, only the current usage. But current usage could be quickly overwhelmed if anything is agreed upon, documented and heavily used. For reference: https://github.com/gravitystorm/openstreetmap-carto/issues/107 was rejected for rendering at openstreetmap-carto but maybe the case can be re-opened later. If there is a need. To Séverin, For your particular case with your students and considering your time frame I would say: IMO it is taggable, no need to avoid in OSM. Go ahead. My preference is either place=block or place=plot. Pick as you wish and set the trend. The hard work is the mapping, tags can be modified if consensus and documentation actually appear. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
On 11.03.2015 17:29, Jan van Bekkum wrote: Perhaps we can extend the library of pictures in the wiki to give people a better feeling which rating means what. I agree that work on the pictures is needed. The values and their verbal descriptions are approved, and they look sound, while the bogus pictures are not approved and they do not match the definitions. We should either replace those pictures or just delete them. It seems to me that these pictures are the root of most of the controversy and the reason why these tags are ignored by most mappers and data consumers. -- 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] [Talk-bf] Buildings blocks
On 11/03/2015 18:04, althio wrote: To Séverin, For your particular case with your students and considering your time frame I would say: IMO it is taggable, no need to avoid in OSM. Go ahead. My preference is either place=block or place=plot. Pick as you wish and set the trend. Why not use both ? The two illustration below illustrate quite well how the city_block is divided into plots: https://upload.wikimedia.org/wikipedia/commons/b/be/City_block.PNG http://i.imgur.com/jbIe1vB.png And it will be a great pedagogical opportunity to explain that not every tag is rendered by the demo rendering openstreetmap.org but that it is nevertheless useful to use it because other renderers or users in general will be able to use it anyway. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Leaf type of palm for leaf_type
On 10.03.2015 21:41, Bryce Nesbitt wrote: I'm seeking comments on adding palm to the leaf types at http://wiki.openstreetmap.org/wiki/Key:leaf_type A rendering engine can equate palm and broadleaved. Mappers are mapping palms very frequently, and having this key name I think would reduce confusion. I am glad you added a palm symbol to http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree#Possible_Rendering. When I created the conversion table in that section, I wondered why there is no palm symbol. I believed that I had already seen a palm symbol somewhere in the wiki, but I didn't manage to retrieve it. Then I searched google for palm symbols, but did not find anything either. So I was finally in doubt whether palm symbols are in use in carthography at all, although I still believe that palm symbols add value to maps. If broad and needle leaved trees get different symbols, palms should get their symbol as well because of their distinctive look. And - but that's just my subjective opinion - palm symbols look so cute that a map becomes more appealing when it incorporates them. Concerning tagging, there has been an approved and widely used key for a long time with exactly the values we need to distinguish palms, needle leaved and broad leaved trees. This key is type=*. This key worked quite well. However, there were two aesthetic issues with that key: That it is also used for relation types, and that there's a different key wood=* used for areas (natural=wood, landuse=forest). These issues evaporate when you look at them from an analytical perspective. type=* of trees never collides with type=* of relations, because trees are not relations. And wood=* has just another purpose. While type=broad_leaved/coniferous/palm defines the *habitus* of a single plant, wood=* describes a *behaviour* of an area. wood=evergreen means that assimilation (photosynthesis) does not change much with the seasons, and that the tree crowns remain continuously opaque. wood=coniferous means that the crowns are constantly semi-opaque, and that assimilation remains also at an intermediate level. wood=deciduous means that both assimilation and opaqueness have big seasonal amplitudes. This tag has enourmous ecological and econimical implications, and it may also be used to determine good times for documention (photographing, creating arial images) and recreational use. It is absolutely useless to use tags the other way round, i.e. plant habitus for forests or assimilation amplitudes for single trees. Therefore, no serious efforts were made to unify these tags, for many years. Then came Rudolf's surprise attack. He created a flawed proposal that missed all of the above points, and pushed it to voting just 3 weeks later. This was a much too short disussion period for a change affecting tremendous amounts of existing data. Many people, including me, did not have enough spare time in that time frame to participate in the discussion and to single out all of the flaws which include: - The wrong interpretation of the rule that type=* for non-relation elements should be avoided. - The mistaken reduction of wood=* to describe the type of leaves. - The wrong assumption that all of these tags mean the same. - The wrong assumption that new keys make things easier. Obviously, the opposite is true, because mappers and applications now need to know the new tags *in addition* to the conventional tags. - An ugly key name leaf_type=* although the more sound foliage=* key had been suggested on Talk:Key:wood as early as in 2012 by Alv. - broadleaved and needleleaved with no underscores - information loss due to the missing equivalent to type=palm - and worst of all, the deprecating established keys thing. There were more than 1 million of uses for wood=* and type=*. How can a proposal deprecate tags used a million times? Do 27 votes on a wiki page legitimate for the deprecation of tags used by 1 distinct mappers on 100 objects? Well, you could think that a proposal is one thing, and actual usage is another thing. Let's see how real mappers will accept it in real life. But in this very case, real world mappers got no chance. Immediately after voting has ended, Rudolf marked type=* and wood=* as deprecated on the natural=tree and wood=* wiki pages. I guess that some JOSM developers wanted to keep their editor cutting-edge by changing templates or suchlike to the new tagging scheme. And some validators spit out warnings when they come across the decprecated tags. As we all now, some sofa mappers spend all day searching for things to correct, using validators. These people do not care about how map features represent the real world, or who mapped them or why, or who will ever use the data. They only care about what the validator says. If a validator blinks red, there's a need to change something, and if it does not blink red, everything is fine. This results in mass edits that violate the mechanical edits policy. But those people do
Re: [Tagging] square_paving_stones:width
W dniu 11.03.2015 17:18, Mateusz Konieczny napisał(a): Key: square_paving_stones:width Value: size of square paving stone in cm. I guess similar schema can be also used with trylinka: https://commons.wikimedia.org/wiki/File:Trylinka.jpg which is quite common in Poland, but: Key: hexagon_paving_stones:width would be ambiguous (is it diamater or the edge?), so I would like to have something more general. -- Piaseczno Miasto Wąskotorowe ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Talk-bf] Buildings blocks
W dniu 11.03.2015 18:04, althio napisał(a): It indeed looks to fit well within the existing scheme as a more refined urban territorial subdivision. place = city/town suburb neighbourhood city_block/block / plot Yet another two, to be complete: ... borough suburb quarter neighbourhood ... [ http://wiki.openstreetmap.org/wiki/Map_Features#Populated_settlements.2C_urban ] They are less popular kind of places, but for example in Warsaw we have official quarters' name on every house number plate. -- Piaseczno Miasto Wąskotorowe ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Talk-bf] Buildings blocks
On 11 March 2015 at 18:14, Jean-Marc Liotier j...@liotier.org wrote: On 11/03/2015 18:04, althio wrote: To Séverin, For your particular case with your students and considering your time frame I would say: IMO it is taggable, no need to avoid in OSM. Go ahead. My preference is either place=block or place=plot. Pick as you wish and set the trend. Why not use both ? The two illustration below illustrate quite well how the city_block is divided into plots: https://upload.wikimedia.org/wikipedia/commons/b/be/City_block.PNG http://i.imgur.com/jbIe1vB.png Indeed both can be used and they are quite clearly defined. It mainly depends on how much details Séverin and the students want to put in the mapping. I think blocks because they are easier to explain, recognise and map. If one wants to map plots/lots, fine! Of course you can also add buildings and walls/fences. And it will be a great pedagogical opportunity to explain that not every tag is rendered by the demo rendering openstreetmap.org but that it is nevertheless useful to use it because other renderers or users in general will be able to use it anyway. Agreed. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Talk-bf] Buildings blocks
On 11 March 2015 at 18:04, althio althio.fo...@gmail.com wrote: The trouble is there is no definition yet of city_block Not so. When I added it to osm wiki I also put there a reference to the definition found in Wikipedia and that's also how I've used the tag. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Buildings blocks
On 11 March 2015 at 20:14, althio althio.fo...@gmail.com wrote: On Mar 11, 2015 7:44 PM, Markus Lindholm markus.lindh...@gmail.com wrote: On 11 March 2015 at 18:04, althio althio.fo...@gmail.com wrote: The trouble is there is no definition yet of city_block Not so. When I added it to osm wiki I also put there a reference to the definition found in Wikipedia and that's also how I've used the tag. I am sorry that I missed your page. I am referring to http://wiki.openstreetmap.org/wiki/Tag:place%3Dcity_block Where is your page? I bit of confusion, I added it here http://wiki.openstreetmap.org/wiki/Map_Features#Populated_settlements.2C_urban and there I also added a link to the Wikipedia definition. Some other people added the the actual page http://wiki.openstreetmap.org/wiki/Tag:place%3Dcity_block I assumed there was a link to Wikipedia from that page also, but now I realize that it is missing. /Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] square_paving_stones:width
Am 11.03.2015 um 17:49 schrieb Friedrich Volkmann b...@volki.at: What about rectangular paving stones? A key paving_stones:length (with a definition like the length the longest horizontal edge) would be more universal. And there should be some default unit (m?). I suggest to define paving stone width as orthogonal to the direction (OK, in diagonal cases it will not work) and length could be in direction. I have some doubt generally that paving stone sizes will become something very common in mapping but this way you could use the 2 tags for detailed rendering or to know how many joints there are for a given way length. Btw, mixed sizes are also very common ;-) cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] square_paving_stones:width
*square_paving_stones:width* may well lead to* trapezoidal_paving_stones:geometry*, and more craziness. How about: *surface=paving_stones* *paving_stones:detail*=whatever you want *paving_stones:detail*=20cm square *paving_stones:detail*=hello kitty shape, 50cm from chin to bow Google has proven that natural language parsing (e.g. pulling the dimensions out of the above) works good enough. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
I consider the definitions quite reasonable for this tag. Yes,there is a degree of subjectiveness there,there has to be given what it is trying to do. Honestly, we really need to got over this dread fear of being subjective. Not everything can be measured in integer numbers, great when it can be but accept it when what is being described is, by its nature, difficult. So I'd vote to remove the controversy section, but perhaps to move it to discussion for historical purposes. Dave S, I think the suggestion of measuring such things using accelerometers was someones sarcastic attempt to show the tag is about as good as it can get. Now, having said that, i don't use the tag because the names used are horrible. Firstly, smoothness itself is not the only issue and the values ?? I live on a road I'd have to call very bad ? No way ! David jgpacker john.pack...@gmail.com wrote: Hi, I saw in the wiki page Key:smoothness http://wiki.openstreetmap.org/wiki/Key:smoothness#Controversy that there is a section about the controversy over it's verifiability. As far as I remember, this tag was throughly discussed here until a consensus was achieved (which was that it should be classified according to how usable the road is/which kinds of modes of transportation can use it). Is this claim over it's verifiability still current? I think it's not, and that this claim should be removed from the page (though it may be useful to write a section with a brief history of this key). Cheers, John -- View this message in context: http://gis.19327.n5.nabble.com/Current-status-of-the-key-smoothness-tp5836692.html Sent from the Tagging mailing list archive at Nabble.com. ___ 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] Leaf type of palm for leaf_type
On 11.03.2015 17:58, Mateusz Konieczny wrote: It's all driven by technocrats who have no clue about what a tree or forest looks like in the real world. Small note, phrases like this are unlikely to be a good idea. Let's assume that technocrats don't read this. :-) -- 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] Survey points
On 12/03/2015 1:43 AM, moltonel 3x Combo wrote: Here is a fine example of this case : http://www.openstreetmap.org/way/236843122 The description tag explains that the reference point is the base of the christian cross on this bell tower. I think it makes sense of mapping this this way : in a sense the whole building *is* the man_made=survey_point. Adding a separate survey_point node would have little benefit. There are other examples like this one, but not all of them have a neat description of where the precise survey point is on the structure. On the other hand, some ways look a bit pointless and could probably be nodes, but a survey is needed to be sure: True 'survey points' are documented with their precise location, date of location and description. So looking at that data would clarify the situation and not require a visit. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk
Summary after 2 weeks of voting; Total votes some 28. Thank you for voting! Some 17 approvals. I'm leaving the voting open for another week. If you have not voted ... Please do so! ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Rendering of individual power lines in residential areas on default osm-carto
Have a peek at: https://www.openstreetmap.org/#map=17/37.64529/-118.97450
Where individual residential power lines are rendered in a cluttered way.
What dividing line can the tagging offer here, to allow rendering to make
better choices?
Here the mapper made some attempt to call these residential lines, but not
enough
to dissuade osm-carto.
---
Separately,what do people think of this lite power tagging scheme as a
solution?
*highway*={any}
*utility_wires*={overhead,underground,none,unknown}
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - Key:Waste Collection
Time to see if there is support to have a new top level key for waste, rather than have many waste values under some other key, for example amenity=sanitary_dump_station. Overview https://wiki.openstreetmap.org/wiki/Proposed_features/waste_collection Voting https://wiki.openstreetmap.org/wiki/Proposed_features/waste_collection Note: The voting is a test of the support for a new top level tap Key:waste_collection= .. not the suggested values on the page .. those are for an indication ONLY .. and should be further discussed and voted on if the proposal is approved. Do note the present voting for another amenity= value of waste collection http://wiki.openstreetmap.org/wiki/Proposed_features/Sanitary_Dump_Station .. if you wish to go down the path of many amenity= waste values. If you are against this proposal you should be for the other? Vote. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Temperature=
Well a summary at ~ 2 weeks Total votes 15. Approvals 7. So it is close. Please vote! In another week I've evaluate the votes and proceed from there. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways
moltonel 3x Combo wrote: I'm playing the devil's advocate a bit here I believe the modern day term for that is trolling, and it wastes everyone's time. The whole railway episode has been really disheartening for the casual disrespect it shows to committed contributors. No-one has a monopoly on deciding what belongs in OSM and what doesn't, but honouring the dedication and commitment of the users who have made our map great must surely be high on the list. We've already imported too much of the bureaucracy and the automate everything attitudes that have damaged the Wikipedia community so. Please let's not adopt deletionism as well. Richard -- View this message in context: http://gis.19327.n5.nabble.com/Blatant-tagging-for-the-renderer-bridges-abandoned-railways-tp5836370p5836644.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Leaf type of palm for leaf_type
There are 533 413 elements with the “leaf_type” key. Only 83 of them have the value “palm”. This are 0.0156 % and certainly not “widely used” at all! I suppose you want to make a mechanical edit to change the existing 13 056 elements with type=palm. But you would change the description of leaf_type=*. You would destroy the clean description of a clean and well-defined key. An important reasons for the introduction of leaf_type=* was that the previous solutions were too complex, not well coordinated, too detailed – and thought didn’t work well. leaf_type=* is an effort to keep things simple and clear. It’s not good to break this. You should not change the description of leaf_type=*. You should use leaf_type=broadleaved and – if you want – add some other tag to make a more exact description. 2015-03-11 4:54 GMT, Bryce Nesbitt bry...@obviously.com: On Tue, Mar 10, 2015 at 9:01 PM, johnw jo...@mac.com wrote: There are places where there are an amazing mount of Palm trees, and confusing them with a broadleaf tree is not great. But is this the main way the species (or class or whatever) of tree is defined? I thought there was some species tag for this as well - or is it too difficult when mapping to know the type of tree beyond it’s leaf? There are species and genus tags, but many mappers won't be able to fill that those. Palm on the other hand is easy, and makes a great map symbol also. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Leaf type of palm for leaf_type
On Tue, Mar 10, 2015 at 11:40 PM, Russell Deffner russell.deff...@hotosm.org wrote: Hi, I hope this helps (and that I’m remembering correctly my education from forestry school in the states), In taxonomy of trees there are two kinds of families - gymnosperms and angiosperms, commonly called deciduous and coniferous but actually scientifically separated by their reproductive difference not what their leaves look like, do, etc. More commonly you here layman terms depending on context: -‘Leaf Type’ (the structure of the leaves): needle, broad and/or palm -‘Leaf Retention’ (if they fall off or not): evergreen, autumn/broad, and/or Palm - ‘Wood Type’ (for wood product industry): soft, hard, exotic/ornamental Araucariaceae happens to be my favourite gymnosperm, but why get all technical? The species= tag is available for that. What you've got there is a good looking list of what's easily observed about an individual tree, which is what most mappers can do. It's pretty close to leaf_type/leaf_cycle and wood, minus the palm trees. Existing land cover databases mostly talk about forests, not trees: http://bioval.jrc.ec.europa.eu/products/glc2000/legend.php http://landcover.usgs.gov/classes.php#upland And mapping individual trees, as many people are doing for whatever reason, is slightly different. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Leaf type of palm for leaf_type
Hi, I hope this helps (and that I’m remembering correctly my education from forestry school in the states), In taxonomy of trees there are two kinds of families - gymnosperms and angiosperms, commonly called deciduous and coniferous but actually scientifically separated by their reproductive difference not what their leaves look like, do, etc. More commonly you here layman terms depending on context: -‘Leaf Type’ (the structure of the leaves): needle, broad and/or palm -‘Leaf Retention’ (if they fall off or not): evergreen, autumn/broad, and/or Palm - ‘Wood Type’ (for wood product industry): soft, hard, exotic/ornamental Maybe we need a key/value for each 'category'; and genus and species is probably best for 'micro-mapping' individual trees or maybe scientific_name=[genus_species] and/or common_name=* example pinus_ponderosa / ponderosa_pine Wish I had more time to work on a proposal/update/upgrade to the wood/natural tagging, but can help answer questions (was going to chime in about the diameter/crown discussion – there’s a whole slew of measurements and how to make them regarding individual trees versus forest plots/stands, etc.) Cheers, =Russ Russell Deffner ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Buildings blocks
Hi, I would like to know if putting building blocks in OSM should be avoided in all cases. I am currently teaching GIS students in Dakar that have ben required to digitize only building blocks on their area of study. Could this been done on OSM (and in that case how to tag it, as for landuse=residential encompass all the areas covered by building blocks and streets?) or always avoided? I did not find the answer in the wiki. Sincerely, Severin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Reception Desk
2015-03-10 22:41 GMT+01:00 David Bannon dban...@internode.on.net: On Tue, 2015-03-10 at 09:35 -0700, Bryce Nesbitt wrote: The wiki has a very low correlation to the rendering. Does it ? Are you suggesting that there is substantial usage of tags that don't appear on the wiki ? If so, I'd suggest we need to fix the wiki. +1 Rendering is not the only goal of OSM data collection. True, but its still the main goal IMHO. Would you suggest otherwise ? this really depends on the kind of use that you intend. routing and geocoding / search / interactive maps are important goals as well. Many attributes that are very common cannot be displayed in a reasonable way in a rendering, at least not all of them. Think the wikipedia tag for instance. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Survey points
OK, the mapper in question did not reply, but silently removed the tags. This leaves me none the wiser as to the more widespread usage of this tag. Looking closer at the data, it appears that man_made=survey_point is very often added to prominent objects, particularly towers, masts and lighthouses. Could it be that some survey agencies use these objects as triangulation points? If so, it raises a couple of issues: 1. The man_made key should refer to the structure, not its usage. 2. The drift towards micro-mapping means that such objects, originally mapped as nodes, get converted to plan outlines and the tags moved to that closed way. If the intent of the survey_point mapper was to set a lat/lon positional reference, then that scheme is undone. Might it not be appropriate to add a note in the Wiki page for this tag that it should not be added it to existing objects, but to always create a separate node? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Leaf type of palm for leaf_type
It would be harder to process and break existing data consumers. I think that cascading tagging style - [leaf_type=broadleaved; broadleaved=palm] would be better. It provides full information without growing list of valid values of leaf_type. 2015-03-11 2:32 GMT+01:00 Bryce Nesbitt bry...@obviously.com: On Tue, Mar 10, 2015 at 3:33 PM, Lukas Sommer sommer...@gmail.com wrote: So it this seems to me that this is just a special case of broadleaved. The difficulty is that palms are widely mapped now, and changing type=palm to leaf_type=broadleaved feels like removing information. Yet that's what the wiki recommends doing. However, leaf_type=palm would loose no data, and still be recognizable as a broadleaved leaf type. ___ 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] Blatant tagging for the renderer: bridges abandoned railways
On 11/03/2015, johnw jo...@mac.com wrote: Actual physical bridges - which may offer the only way across a ravine, or a landmark to where you are on a river sounds like a similar justification - so rendering abandoned, yet physically existing bridges seems like exactly the kind of thing that would be included - especially since their inclusion would offer no clutter or distraction at levels where other items would cause quite a lot of visual clutter for similar orinentation benefit. [...] Again : the osm-carto dev agree that all bridges should be rendered. It's two longstanding bugs, it takes time to fix. Not rendering abandoned railways (wether or not on top of a bridge which should itself be rendered) is a separate issue (this time not a bug but a conscious decision). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Leaf type of palm for leaf_type
+1 Gesendet:Mittwoch, 11. Mrz 2015 um 08:13 Uhr Von:Lukas Sommer sommer...@gmail.com An:Tag discussion, strategy and related tools tagging@openstreetmap.org Betreff:Re: [Tagging] Leaf type of palm for leaf_type There are 533413 elements with the leaf_type key. Only 83 of them have the value palm. This are 0.0156% and certainly not widely used at all! I suppose you want to make a mechanical edit to change the existing 13 056 elements with type=palm. But you would change the description of leaf_type=*. You would destroy the clean description of a clean and well-defined key. An important reasons for the introduction of leaf_type=* was that the previous solutions were too complex, not well coordinated, too detailed and thought didnt work well. leaf_type=* is an effort to keep things simple and clear. Its not good to break this. You should not change the description of leaf_type=*. You should use leaf_type=broadleaved and if you want add some other tag to make a more exact description. 2015-03-11 4:54 GMT, Bryce Nesbitt bry...@obviously.com: On Tue, Mar 10, 2015 at 9:01 PM, johnw jo...@mac.com wrote: There are places where there are an amazing mount of Palm trees, and confusing them with a broadleaf tree is not great. But is this the main way the species (or class or whatever) of tree is defined? I thought there was some species tag for this as well - or is it too difficult when mapping to know the type of tree beyond its leaf? There are species and genus tags, but many mappers wont be able to fill that those. Palm on the other hand is easy, and makes a great map symbol also. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Lukas Sommer ___ 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] Leaf type of palm for leaf_type
I oppose this suggestion. The key:leaf_type should be as simple as possible. Palms are included in leaf_type=broadleaved. The values relate to the Land Cover Classification System (LCCS) by FAO. I dont know any classification systems with leaf_type=palm. To refine the tagging you can use key:species or key:genus or key:taxon. Im not sure which will fit the best. Gesendet:Dienstag, 10. Mrz 2015 um 21:41 Uhr Von:Bryce Nesbitt bry...@obviously.com An:Tag discussion, strategy and related tools tagging@openstreetmap.org Betreff:[Tagging] Leaf type of palm for leaf_type Im seeking comments on adding palm to the leaf types at http://wiki.openstreetmap.org/wiki/Key:leaf_type A rendering engine can equate palm and broadleaved. Mappers are mapping palms very frequently, and having this key name I think would reduce confusion. ___ 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] Buildings blocks
2015-03-11 12:12 GMT+01:00 Severin Menard severin.men...@gmail.com: I would like to know if putting building blocks in OSM should be avoided in all cases. I am currently teaching GIS students in Dakar that have ben required to digitize only building blocks on their area of study. Could this been done on OSM (and in that case how to tag it, as for landuse=residential encompass all the areas covered by building blocks and streets?) or always avoided? I did not find the answer in the wiki. There is no general answer to this question. My personal suggestion is to tag them with landuse=residential and not include the streets (if they're actually residential areas), or commercial, retail etc. according to what is there. You might also want to split the block into more than one landuse if it is required to better represent reality. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Leaf type of palm for leaf_type
2015-03-11 12:24 GMT+01:00 Rudolf Martin rudolf.mar...@gmx.de: Perhaps we can find a general simple tagging for palms. key:genus and key:species expect the scientific name of a plant. These are normaly not known to non-botanists. you could also use common names, e.g. species:de=Ölpalme or species:en=oil_palm but you'd still have to know the species quite well in order to be able to use these tags. taxon:en=palm may be a good solution, although I would prefer taxon=palm. Unfortunable the latter don't fit to the taxon definition. I think it is important to have the language suffix when tagging common names, otherwise we'd end up with a mess. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Survey points
On 11/03/2015 10:23, Malcolm Herring wrote: On 11/03/2015 09:46, moltonel 3x Combo wrote: Care to review them ? I took a quick look at these objects the few that I examined were actually created as areas, rather than had been converted from a node. The most egregious example is this one: http://www.openstreetmap.org/way/199650922. It is a square with sides over 500m, and a note that reads do not move this node!!?? Looking at the edit, that's more likely to be a just newbie faux pas isn't it? The do not move this node stuff is used regularly for French survey points. May this is the survey point: https://www.openstreetmap.org/node/2096332697 Perhaps a changeset discussion comment or OSM note might be the way forward? Cheers, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Survey points
On 11/03/2015, Malcolm Herring malcolm.herr...@btinternet.com wrote: I took a quick look at these objects the few that I examined were actually created as areas, rather than had been converted from a node. The most egregious example is this one: http://www.openstreetmap.org/way/199650922. It is a square with sides over 500m, and a note that reads do not move this node!!?? Fixed. See http://www.openstreetmap.org/node/670609313/history which was part of the way and is the original proper survey point. Luckily the point was not moved (just got its tags deleted) and was retained as part of the way. The contributor probably used the replace geometry action from utilsplugin2. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Leaf type of palm for leaf_type
2015-03-11 7:40 GMT+01:00 Russell Deffner russell.deff...@hotosm.org: In taxonomy of trees there are two kinds of families - gymnosperms and angiosperms, commonly called deciduous and coniferous but actually scientifically separated by their reproductive difference not what their leaves look like, do, etc. Not that I knew better, but I've looked it up ;-) If I understood this page correctly, angiosperms are not a family in the taxon sense but something higher than an order: en.wikipedia.org/wiki/Flowering_plant See here for the taxon hierarchy: http://en.wikipedia.org/wiki/File:Biological_classification_L_Pengo_vflip.svg cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways
On 11/03/2015, Richard Fairhurst rich...@systemed.net wrote: moltonel 3x Combo wrote: I'm playing the devil's advocate a bit here I believe the modern day term for that is trolling, and it wastes everyone's time. Sorry if looked like trolling. I was genuinely trying to show both sides of the argument, as a way to soften conflicts ahead of time (since as far as I can tell they'll continue to happen). My devil's advocate remark was indented to clarify that defending one argument doesn't mean that I blindly always side with that camp. The whole railway episode has been really disheartening for the casual disrespect it shows to committed contributors. No-one has a monopoly on deciding what belongs in OSM and what doesn't, but honouring the dedication and commitment of the users who have made our map great must surely be high on the list. We've already imported too much of the bureaucracy and the automate everything attitudes that have damaged the Wikipedia community so. Please let's not adopt deletionism as well. Agreed. I always strive to be conservative and chatty when touching somebody else's work, railway or otherwise. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways
2015-03-11 11:10 GMT+01:00 moltonel 3x Combo molto...@gmail.com: Again : the osm-carto dev agree that all bridges should be rendered. It's two longstanding bugs, it takes time to fix. Not rendering abandoned railways (wether or not on top of a bridge which should itself be rendered) is a separate issue (this time not a bug but a conscious decision). if the bridge is not mapped, but just an attribute to another feature (here abandoned railway), and that other feature doesn't get rendered anymore, it might seem for mappers interested in that feature that the issues are intertwined. I agree they are not. Also abandoned features do not guarantee that the bridge is still physically present or usable. I hope (and believe) that the carto-osm-style will soon render man_made=bridge objects, so that bridges can be rendered as objects on their own. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Survey points
On 11/03/2015, Malcolm Herring malcolm.herr...@btinternet.com wrote: OK, the mapper in question did not reply, but silently removed the tags. This leaves me none the wiser as to the more widespread usage of this tag. At least that's reassurance that a buoy, which can drift quite a bit on the surface, isn't considered as a survey point :p Looking closer at the data, it appears that man_made=survey_point is very often added to prominent objects, particularly towers, masts and lighthouses. Could it be that some survey agencies use these objects as triangulation points? Often yes. And to make that survey point official when it isn't a purpose-built structure, there is often a reference plaque placed on the structure at the exact location of the point. If so, it raises a couple of issues: 1. The man_made key should refer to the structure, not its usage. 2. The drift towards micro-mapping means that such objects, originally mapped as nodes, get converted to plan outlines and the tags moved to that closed way. If the intent of the survey_point mapper was to set a lat/lon positional reference, then that scheme is undone. Might it not be appropriate to add a note in the Wiki page for this tag that it should not be added it to existing objects, but to always create a separate node? The wiki already mentions that the tag only applies to nodes, which should in theory catch upgraded to an area mishapps. There are currently 64 survey_point ways in the db (compared to 287000 nodes), so the problem exists but isn't too big. Care to review them ? That said, a always add survey points as their own node recommendation on the wiki can't hurt. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Leaf type of palm for leaf_type
2015-03-11 5:54 GMT+01:00 Bryce Nesbitt bry...@obviously.com: There are species and genus tags, but many mappers won't be able to fill that those. Palm on the other hand is easy, and makes a great map symbol also. If you're not sure about the genus or species, you could also use more generic taxon like family=Arecaceae or common names, like family:en=palm Or following this page: http://wiki.openstreetmap.org/wiki/Key:taxon taxon:family=Arecaceae taxon:family:en=palm or if you don't know that palms are a family: taxon:en=palm (at least that's what the taxon page suggests). Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - shop=storage
To avoid confusion the wiki page has been renamed to reflect the change of the proposal itself that was made before the proposal was submitted for voting. It now can be found here: http://wiki.openstreetmap.org/wiki/Proposed_features/shop%3Dstorage#Tagging. Furthermore I elaborated the reasoning for the proposal as it is a bit more in the paragraph Tagging. Regards, Jan van Bekkum On Tue, Mar 10, 2015 at 10:13 PM Bryce Nesbitt bry...@obviously.com wrote: There a move page link that leads to Special:MovePage, for renaming pages. ___ 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] Buildings blocks
W dniu 11.03.2015 13:06, Martin Koppenhoefer napisał(a): maybe a new place value? Of the existing ones, maybe place=neighbourhood? Although this is a really small nieghbourhood compared to other areas with this tag. Probably place=city_block is exactly what you're looking for: http://wiki.openstreetmap.org/wiki/Tag:place%3Dcity_block https://en.wikipedia.org/wiki/City_block -- Piaseczno Miasto Wąskotorowe ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
I search an adjective about this tag and I hesitate between very_bad and horrible ;-) Btw, what's different today about its verifiability ? I think most of the people rejecting this tag simply ignore the discussions around it. This gives a different perspective about your consensus. Removing the controversy section will just give the false impression that there is no controversy at all. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
On 11.03.2015 12:56, jgpacker wrote: Is this claim over it's verifiability still current? Yes, it is, because the photos contradict the verbal value definitions. -- 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] [Talk-bf] Buildings blocks
I do not have the answer but I wanted to look towards place=* tagged as area. A few possibilities may include: place=block [taginfo ~1 200 as area] [no wiki] place=city_block [taginfo ~900 as area] [wiki documentation, mostly in Stockholm, Sweden] place=plot [taginfo ~900 as area] [no wiki] place=neighbourhood [taginfo ~7 000 as area] [wiki, requires name according to documentation] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Survey points
A survey point is those brass markers in the ground - an official X in the ground of some kind. I assume a tower on a distant mountain is a survey_reference_object or similar. It certainly isn't a point. Javbw On Mar 11, 2015, at 5:46 PM, Malcolm Herring malcolm.herr...@btinternet.com wrote: OK, the mapper in question did not reply, but silently removed the tags. This leaves me none the wiser as to the more widespread usage of this tag. Looking closer at the data, it appears that man_made=survey_point is very often added to prominent objects, particularly towers, masts and lighthouses. Could it be that some survey agencies use these objects as triangulation points? If so, it raises a couple of issues: 1. The man_made key should refer to the structure, not its usage. 2. The drift towards micro-mapping means that such objects, originally mapped as nodes, get converted to plan outlines and the tags moved to that closed way. If the intent of the survey_point mapper was to set a lat/lon positional reference, then that scheme is undone. Might it not be appropriate to add a note in the Wiki page for this tag that it should not be added it to existing objects, but to always create a separate node? ___ 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] Current status of the key smoothness=*
Hi, I saw in the wiki page Key:smoothness http://wiki.openstreetmap.org/wiki/Key:smoothness#Controversy that there is a section about the controversy over it's verifiability. As far as I remember, this tag was throughly discussed here until a consensus was achieved (which was that it should be classified according to how usable the road is/which kinds of modes of transportation can use it). Is this claim over it's verifiability still current? I think it's not, and that this claim should be removed from the page (though it may be useful to write a section with a brief history of this key). Cheers, John -- View this message in context: http://gis.19327.n5.nabble.com/Current-status-of-the-key-smoothness-tp5836692.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Survey points
On 11/03/2015 11:57, Martin Koppenhoefer wrote: maybe the tower has a point defined (e.g. top of the antenna or a sign or similar) which could be a survey_point. Since surveyors have to take bearings-from as well as bearings-to survey points, the point would have to be located where survey instruments can be set up. One would expect, therefore, that these points would be at ground level. That is how the Wiki illustrates them. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Buildings blocks
2015-03-11 12:56 GMT+01:00 Jean-Marc Liotier j...@liotier.org: As you can see, each block is subdivided into land plots - each with a courtyard and several buildings that usually all belong to an extended family. Those land plots have a strong significance and the frequent sighting of spontaneous attempts by to map them in various ways is testimony to that. I do not yet have an answer to this requirement - it should obviously be mapped as an area but I have so far failed to select satisfactory attributes to model it. I believe that landuse=* is not suitable - in Senegal, as http://wiki.openstreetmap.org/wiki/FR:WikiProject_Senegal recommends, the whole urban area is landuse=residential, so it is not available to map smaller subdivisions. maybe a new place value? Of the existing ones, maybe place=neighbourhood? Although this is a really small nieghbourhood compared to other areas with this tag. I don't see a problem in the whole area being landuse=residential, still you could split these into several smaller landuse=residential, but I agree that there will be no inherent semantics about the special situation there with just the landuse tag. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Buildings blocks
On 11/03/2015 12:22, Martin Koppenhoefer wrote: 2015-03-11 12:12 GMT+01:00 Severin Menard severin.men...@gmail.com mailto:severin.men...@gmail.com: I would like to know if putting building blocks in OSM should be avoided in all cases. I am currently teaching GIS students in Dakar that have ben required to digitize only building blocks on their area of study. Could this been done on OSM (and in that case how to tag it, as for landuse=residential encompass all the areas covered by building blocks and streets?) or always avoided? I did not find the answer in the wiki. There is no general answer to this question. My personal suggestion is to tag them with landuse=residential and not include the streets (if they're actually residential areas), or commercial, retail etc. according to what is there. You might also want to split the block into more than one landuse if it is required to better represent reality. Is it actually the building blocks that they want to map ? Or the urban land plots that often form a unit of habitation in moderately dense African cities ? I suspect that this thread is about the latter. I am somewhat active in mapping Senegal and I have witnessed many attempts to map the fine subdivisions of the urban fabric - the whole plot mapped as a building, just its limit mapped as a wall, just a name with no other attribute, a landuse, or quite a few other creative misguided combinations that show that people really want to map that even if the editor shows no preset to that effect. Those not used to map Senegal can take a look at the following orbital imagery for illustrations of what I have in mind: http://i.imgur.com/jbIe1vB.png http://i.imgur.com/8BvdP30.png As you can see, each block is subdivided into land plots - each with a courtyard and several buildings that usually all belong to an extended family. Those land plots have a strong significance and the frequent sighting of spontaneous attempts by to map them in various ways is testimony to that. I do not yet have an answer to this requirement - it should obviously be mapped as an area but I have so far failed to select satisfactory attributes to model it. I believe that landuse=* is not suitable - in Senegal, as http://wiki.openstreetmap.org/wiki/FR:WikiProject_Senegal recommends, the whole urban area is landuse=residential, so it is not available to map smaller subdivisions. cc: Augustin who might be able to tell us about how this issue is perceived in Burkina Faso. (The two images above are also provide good examples of one of my pet peeves: the Senegalese spaghetti way syndrome - this is entirely off-topic but having corrected so many of them over the years I just felt a strong need to share it with someone) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Survey points
2015-03-11 12:49 GMT+01:00 John Willis jo...@mac.com: I assume a tower on a distant mountain is a survey_reference_object or similar. It certainly isn't a point. maybe the tower has a point defined (e.g. top of the antenna or a sign or similar) which could be a survey_point. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
I'm not sure much can be done about the situation. Verifiability depends on one person's subjective assessment of the smoothness of a road. The illustration in the Wiki of a road that is impassable can be negotiated by a skilled rider on a mountain bike. During the discussion of this topic someone suggested trying to make a quantitative measurement of smoothness by attaching some sort of gyroscope or accelerometer to a vehicle's bumper in order to produce a number. On Wed, Mar 11, 2015 at 6:56 PM, jgpacker john.pack...@gmail.com wrote: Hi, I saw in the wiki page Key:smoothness http://wiki.openstreetmap.org/wiki/Key:smoothness#Controversy that there is a section about the controversy over it's verifiability. As far as I remember, this tag was throughly discussed here until a consensus was achieved (which was that it should be classified according to how usable the road is/which kinds of modes of transportation can use it). Is this claim over it's verifiability still current? I think it's not, and that this claim should be removed from the page (though it may be useful to write a section with a brief history of this key). Cheers, John -- View this message in context: http://gis.19327.n5.nabble.com/Current-status-of-the-key-smoothness-tp5836692.html Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - Reception Desk
On Wed, Mar 11, 2015 at 5:47 PM, Warin 61sundow...@gmail.com wrote: Summary after 2 weeks of voting; Total votes some 28. Thank you for voting! Some 17 approvals. The level of opposition -- regardless of the technical count -- indicates the proposal can use some improvement. I urge any person getting this level of opposition to reconsider, resolve the issues, and resubmit. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Regional stylesheets for osm-carto (Was: rendering of local power lines)
On Wed, Mar 11, 2015 at 7:21 PM, johnw jo...@mac.com wrote: In certain countries (such as the one I am in) the thick black line has a single purpose - private train lines. The zebra striped lines -carto uses are for national lines only (JR lines in Japan), and the thick black lines are for private railways (such as most of the Tokyo subway system) that run across the country. Two of the three train lines in my city should be black lines. So thick black trunk lines makes it look like there are train lines all over my province that don’t exist, which is a real detriment to the OSM/-carto render in Japan. adding neighborhood lines would be even worse. -1 for thread hijacking, but +1 on the thought. There ARE regional differences in rendering preferences. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
I am a little unsure what the problem is with the pictures. Could you be a bit more specific please Friedrich ? It would be very hard to have a set of pictures that cover every case but, as Jan said, if we are only one level out, thats still very useful information. Honestly, while not very clear, the pictures look about right to me. David . Friedrich Volkmann b...@volki.at wrote: On 11.03.2015 17:29, Jan van Bekkum wrote: Perhaps we can extend the library of pictures in the wiki to give people a better feeling which rating means what. I agree that work on the pictures is needed. The values and their verbal descriptions are approved, and they look sound, while the bogus pictures are not approved and they do not match the definitions. We should either replace those pictures or just delete them. It seems to me that these pictures are the root of most of the controversy and the reason why these tags are ignored by most mappers and data consumers. -- 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] [Talk-bf] Buildings blocks
Am 11.03.2015 um 19:43 schrieb Markus Lindholm markus.lindh...@gmail.com: reference to the definition found in Wikipedia and that's also how I've used the tag. and if someone changes the Wikipedia page, the definition for our tag will change as well? cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rendering of individual power lines in residential areas on default osm-carto
Hi Bryce,
If find your example really good, thank you to have find such a nice place
:)
I don't agree to use highway=* + utility_wires because of the lack of
information it introduces.
The member nodes of the highway=* way won't reflect the real position of
(and some other details about) the poles supporting utilities networks
beside the road.
Since only the render is affected by such a level of details, only the
render should be updated.
Those power lines can be selected by their voltage=low tag.
As it has already been discussed here and on several wiki Talk pages,
voltage - not the one but part of - some serious scale factors to get the
importance of power lines.
Currently, power lines are concerned by a few proposals :
https://wiki.openstreetmap.org/wiki/Proposed_features/Power_supports_refinement
https://wiki.openstreetmap.org/wiki/Proposed_features/Power_paths_refinement
All the best
*François Lacombe*
fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux http://www.twitter.com/InfosReseaux
2015-03-11 23:20 GMT+01:00 Bryce Nesbitt bry...@obviously.com:
Have a peek at: https://www.openstreetmap.org/#map=17/37.64529/-118.97450
Where individual residential power lines are rendered in a cluttered way.
What dividing line can the tagging offer here, to allow rendering to make
better choices?
Here the mapper made some attempt to call these residential lines, but not
enough
to dissuade osm-carto.
---
Separately,what do people think of this lite power tagging scheme as a
solution?
*highway*={any}
*utility_wires*={overhead,underground,none,unknown}
___
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] Survey points
On 11/03/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2015-03-11 12:49 GMT+01:00 John Willis jo...@mac.com: I assume a tower on a distant mountain is a survey_reference_object or similar. It certainly isn't a point. maybe the tower has a point defined (e.g. top of the antenna or a sign or similar) which could be a survey_point. Here is a fine example of this case : http://www.openstreetmap.org/way/236843122 The description tag explains that the reference point is the base of the christian cross on this bell tower. I think it makes sense of mapping this this way : in a sense the whole building *is* the man_made=survey_point. Adding a separate survey_point node would have little benefit. There are other examples like this one, but not all of them have a neat description of where the precise survey point is on the structure. On the other hand, some ways look a bit pointless and could probably be nodes, but a survey is needed to be sure: http://www.openstreetmap.org/way/4041174 http://www.openstreetmap.org/way/315474577 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [Talk-bf] Buildings blocks
On 11/03/2015 13:25, althio wrote: I do not have the answer but I wanted to look towards place=* tagged as area. I like that approach - it will let us position this entity within the existing frame of concentric urban territorial subdivisions. place=block [taginfo ~1 200 as area] [no wiki] place=city_block [taginfo ~900 as area] [wiki documentation, mostly in Stockholm, Sweden] Too big: looking at http://i.imgur.com/jbIe1vB.png shows that the city block encompasses eight to ten of the entities we seek to tag - numbers may of course vary worldwide, but the hierarchy will be the same. place=neighbourhood [taginfo ~7 000 as area] [wiki, requires name according to documentation] Too big - even more than the block since is a neighborhood might encompass several blocks. place=plot [taginfo ~900 as area] [no wiki] I like that one a lot - looks very promising to me ! And look at http://www.openstreetmap.org/way/287224897 - it looks like UNHCR in Jordan follows the same line of thinking: addr:postcode=JORZARV06B10P10 admin_level=10 bid=B10 blocdesc=Block 10 boundary =administrative gid=271 name=Plot 10 pid=P10 place=plot refugee=yes vid=V06 vildesc=Village 6 I object to admin_level=10 since http://wiki.openstreetmap.org/wiki/Tag:admin_level%3D10#11_admin_level_values_for_specific_countries most often uses that for place=neighbourhood but apart from that it looks very similar to what we want to model. I would rather chose admin_level=11 which is not documented - though it has 4355 occurrences (http://taginfo.openstreetmap.org/search?q=admin_level%3D11) In the same reasoning I mentioned for not considering place=block and place=city_block, it has blocdesc=Block 10 (which incidentally has a strong smell of UNHCR proprietary tagging - someone tell them that place=block and place=city_block exist ?) Let's look at how it looks like on the ground: http://i.imgur.com/Ai2KgcB.png - it is in a refugee camp, but I'm convinced it is the same concept (and the way the Syrian conflict is going, come back in five years and it will look exactly the same as the Senegal example). Or look at Mama Muga's Plot in Kibera : http://www.openstreetmap.org/node/612007108 - definitely the concept we have been discussing, mapped as place=plot As a bonus, it has some degree of kinship with the concept of 'cadastral plot' which is its more administrative cousin. Color me convinced - place=plot has my vote ! ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Leaf type of palm for leaf_type
Ok, I’m not sure that ‘family’ is the correct taxonomy for angio/gymnosperms (maybe it’s some sort of sub-order), or maybe that wiki-page is just bad; here’s another by comparison that seems to match my memory: http://en.wikipedia.org/wiki/List_of_trees_and_shrubs_by_taxonomic_family I’ll admit, I concentrated in Fire Science, so tree/plant ID and such wasn’t as important to me as intensity and spread which use a whole other classification system for ‘fuel type’ =Russ From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Sent: Wednesday, March 11, 2015 3:44 AM To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Leaf type of palm for leaf_type 2015-03-11 7:40 GMT+01:00 Russell Deffner russell.deff...@hotosm.org: In taxonomy of trees there are two kinds of families - gymnosperms and angiosperms, commonly called deciduous and coniferous but actually scientifically separated by their reproductive difference not what their leaves look like, do, etc. Not that I knew better, but I've looked it up ;-) If I understood this page correctly, angiosperms are not a family in the taxon sense but something higher than an order: en.wikipedia.org/wiki/Flowering_plant See here for the taxon hierarchy: http://en.wikipedia.org/wiki/File:Biological_classification_L_Pengo_vflip.svg cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Haul Channel
On 11/03/2015 4:06 AM, Sam Dyck wrote: In Canada, privately licensed frequencies, not CB are used that have to be programmed into the scanner. There may or may not be repeaters, but since you only need to communicate with the traffic nearby it doesn't matter (there's no point in know that there is a truck moving 20km up the road. The system does not excuse bad driving, nor does it replace a satellite phone. What I assume Warin is talking about is extremely remote tracks with extremely low traffic, but the roads I'm referring to are logging or winter roads, which are remote, narrow and have heavy equipment moving down them at times (but at other times are empty) In my part of Canada such roads are open to the public and often accommodate different groups of people with different vehicles (everything from tractor trailers to long distance runners) Ok.. so the tagging would be usefull for visitors to listen in to any transmissions (probably only the large transports using it). Using a scanner means they cannot transmit back. So the communication is receive only for the public. It would not provide emergency contact for the public unless a vehicle equipped with a transceiver happens along. I don't think this is in use in Australia .. 'we' tend to use the CB radio as that allows most people to not only listen but respond also. The CB radios tend to be cheaper, less restrictive/costly licensing. They are used for local traffic details .. you don't want to be cresting a sand dune with on coming traffic! For remote locations, Australia has the 'Royal Flying Doctor Service' radio ... those can be hired (or purchased) and used in remote areas, they don't provide road information but are for emergency contact, most people are changing over to satellite phone for direct contact rather than through the RFDS. What other parts of the world do you think might use this Canadian method? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Haul Channel
On 11/03/2015 4:06 AM, Sam Dyck wrote: In Canada, privately licensed frequencies, not CB Humm Why call it a 'channel'? And not 'frequency? Might reduce confusion with CB radio channels? thus haul_frequency=* haul_frequency:transmit=* haul_frequency:receive=* Channel 9 is a CB radio thing ... used for conversations There is a list of them here http://www.exploroz.com/Vehicle/Accessories/UHFRadio.aspx I'd think the trucking companies there would have CB radios fitted .. so they can contact people on the road .. not just their own trucks. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rendering of individual power lines in residential areas on default osm-carto
On Wed, Mar 11, 2015 at 4:35 PM, François Lacombe fl.infosrese...@gmail.com wrote: I don't agree to use highway=* + utility_wires because of the lack of information it introduces. The member nodes of the highway=* way won't reflect the real position of (and some other details about) the poles supporting utilities networks beside the road. I don't care to map to a greater level of detail. So the utility_wires tag adds *more* information than *no* information. I do of course realize this is less detail than tagging each pole, lamp stand and bird nest. -- That said, the two schemes don't seem particularly incompatible either. The utility undergrounding information, even just on a road by road basis, is important in terms of emergency services and after huge storms. In California where I live communities vie for conversion to underground utilities for these reasons among others. --- The rendering folks need fairly simple rules to go by. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Rendering of individual power lines in residential areas on default osm-carto
I really dislike strong black renderings for power lines, if they are rendered at all. I opened a ticket in which I was told it was my fault for thinking it it was a bad idea and to stop complaining or claiming persecution (which was really really weird). Others mentioned that the stylesheet may be updated in the future. Flexibility of the stylesheet is a must to adapt to local conditions and labeling customs, in the same way the map accommodates languages other than English. https://github.com/gravitystorm/openstreetmap-carto/issues/1260 In OSM, so many things man made, especially ways, go from light colors (local roads) to brighter colors (Tollways, trunk roads) to how importance. Black lines are walls and barriers of some kind - embankments, bridge casings, retaining walls, or a mode of transportation, aerialways or the like. Then, for some bizarre reason, there are black power lines. You can see the towers, but the lines are not a barrier to movement, not a (human) transportation method, and look like retaining walls over the road. They should not be rendered in -carto at all, or at best a very light grey line - anything but a solid black wall/areialway running across/over streets and hillsides, train lines, and whatnot when they serve no transportation purpose nor offer any barrier. it is a direct conflict to the stylesheet. Also: Having the trunk lines rendered is a big negative, though the towers are visible landmarks. the local lines are less important than hedges or walls. they are background noise. There are so many neighboorhood wires here in Japan that every neighborhood would like a plate of black spaghetti. The amount of wires, even in rural areas, is surprising. In suburban areas, the mess would be catastrophic. rural https://www.flickr.com/photos/javbw/11091291246/in/set-72157638113676925 https://www.flickr.com/photos/javbw/11091291246/in/set-72157638113676925 suburban https://www.flickr.com/photos/javbw/11091343673/in/set-72157638113676925 https://www.flickr.com/photos/javbw/11091343673/in/set-72157638113676925 and, when combined with other rendering choices, the problem is compounded. In certain countries (such as the one I am in) the thick black line has a single purpose - private train lines. The zebra striped lines -carto uses are for national lines only (JR lines in Japan), and the thick black lines are for private railways (such as most of the Tokyo subway system) that run across the country. Two of the three train lines in my city should be black lines. So thick black trunk lines makes it look like there are train lines all over my province that don’t exist, which is a real detriment to the OSM/-carto render in Japan. adding neighborhood lines would be even worse. This system of labeling was adopted in Japan to more easily differentiate the lines and systems sometime between 1945 and 1965, as I have official city maps for my area from 1921, 1945, 1965, and 2007. The 1965 map uses the labeling all Japanese maps and other websites use now, which is not possible to implement currently in -carto. This makes the map the odd-man-out and much more difficult to orient yourself on at important city-wide zoom levels, and confusing in areas where different train lines meet. The inability to properly render train lines in a manner used the by local populations *around the world* (not just for me and my little area, as was claimed) and using the zebra stripe for all standard train lines is a detriment to the map. coupled with the unnecessary prominence of the power lines, these two issues create a very bad combination in some places, though it is particularly bad in Japan. Javbw ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
