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_typ

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 o

Re: [Tagging] Leaf type of "palm" for leaf_type

On Tue, Mar 10, 2015 at 11:40 PM, Russell Deffner 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 conifer

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 light

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 : > On Tue, M

Re: [Tagging] Leaf type of "palm" for leaf_type

2015-03-11 5:54 GMT+01:00 Bryce Nesbitt : > 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 fa

Re: [Tagging] Leaf type of "palm" for leaf_type

2015-03-11 7:40 GMT+01:00 Russell Deffner : > 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 t

Re: [Tagging] Survey points

On 11/03/2015, Malcolm Herring 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

Re: [Tagging] Blatant tagging for the renderer: bridges & abandoned railways

On 11/03/2015, Richard Fairhurst 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

Re: [Tagging] Blatant tagging for the renderer: bridges & abandoned railways

On 11/03/2015, johnw 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 inc

Re: [Tagging] Survey points

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. I

Re: [Tagging] Blatant tagging for the renderer: bridges & abandoned railways

2015-03-11 11:10 GMT+01:00 moltonel 3x Combo : > 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 (thi

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:

Re: [Tagging] Survey points

On 11/03/2015, Malcolm Herring 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 > o

[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=resid

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 don't know any classification systems with leaf_type=palm.   To refine the tagging you can

Re: [Tagging] Leaf type of "palm" for leaf_type

+1     Gesendet: Mittwoch, 11. März 2015 um 08:13 Uhr Von: "Lukas Sommer" An: "Tag discussion, strategy and related tools" Betreff: 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 % an

Re: [Tagging] Buildings blocks

2015-03-11 12:12 GMT+01:00 Severin Menard : > 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

Re: [Tagging] Leaf type of "palm" for leaf_type

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.   "taxon:en=palm" may be a good solution, although I would prefer "taxon=palm". Unfortunable the latter don't fit to the taxo

Re: [Tagging] Feature Proposal - RFC - Reception Desk

2015-03-10 22:41 GMT+01:00 David Bannon : > 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 fi

Re: [Tagging] Leaf type of "palm" for leaf_type

2015-03-11 12:24 GMT+01:00 Rudolf Martin : > 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_p

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 > wrote: > > OK, the mapper in

[Tagging] Current status of the key smoothness=*

Hi, I saw in the wiki page Key:smoothness 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

Re: [Tagging] Buildings blocks

On 11/03/2015 12:22, Martin Koppenhoefer wrote: 2015-03-11 12:12 GMT+01:00 Severin Menard >: 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

Re: [Tagging] Survey points

2015-03-11 12:49 GMT+01:00 John Willis : > 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 ___

Re: [Tagging] Buildings blocks

2015-03-11 12:56 GMT+01:00 Jean-Marc Liotier : > 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

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 ins

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 __

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] p

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 someo

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

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.ope

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]

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 ad

Re: [Tagging] Survey points

On 11/03/2015, Martin Koppenhoefer wrote: > 2015-03-11 12:49 GMT+01:00 John Willis : > >> 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 c

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 an

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 ma

Re: [Tagging] [Talk-bf] Buildings blocks

> Am 11.03.2015 um 14:59 schrieb Jean-Marc Liotier : > > 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

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

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_pa

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 woul

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: > values. To offer better alternative for storing information about size of > square paving stones I am > proposing this tag. What about rectangular paving stones

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 : > On 10.03.2015 21:41, Bryce Nesbitt wrote: > > I'm seeking comments on addin

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_

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 : 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.

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 us

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

Re: [Tagging] [Talk-bf] Buildings blocks

On 11 March 2015 at 18:04, althio 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 ___

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

Re: [Tagging] Buildings blocks

On 11 March 2015 at 20:14, althio wrote: > > On Mar 11, 2015 7:44 PM, "Markus Lindholm" > wrote: >> >> On 11 March 2015 at 18:04, althio 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

Re: [Tagging] square_paving_stones:width

> Am 11.03.2015 um 17:49 schrieb Friedrich Volkmann : > > 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 sto

Re: [Tagging] [Talk-bf] Buildings blocks

On 11 March 2015 at 18:14, Jean-Marc Liotier 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

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 > neighb

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. Volk

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 b

[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

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 cle

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 sens

Re: [Tagging] [Talk-bf] Buildings blocks

> Am 11.03.2015 um 19:43 schrieb Markus Lindholm : > > 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 ___

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 pole

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.

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/taggi

[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/

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

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 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

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

[Tagging] Regional stylesheets for osm-carto (Was: rendering of local power lines)

On Wed, Mar 11, 2015 at 7:21 PM, johnw 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 rail

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

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

Re: [Tagging] Current status of the key smoothness=*

I don't say that the pictures are wrong, but it would be helpful to have perhaps six representative pictures of every level. Related question: does the tag only cover uneven ground or also for example also deep soft sand that may be difficult to cross. The tag surface=sand in itself doesn't tell m

Re: [Tagging] Current status of the key smoothness=*

On 12/03/2015 5:05 PM, Jan van Bekkum wrote: but the bottom line question is: how hard is it to pass with a 2WD, 4WD, motorcycle etc. That is a very complex question. You may add bicycle to the vehicles too. Animals and humans .. too? Soft surfaces may not support the vehicle weight (given a

Re: [Tagging] Current status of the key smoothness=*

On 11.03.2015 23:23, David wrote: > 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 usefu

Re: [Tagging] [Talk-bf] Buildings blocks

On 11 March 2015 at 23:52, Martin Koppenhoefer wrote: >> Am 11.03.2015 um 19:43 schrieb Markus Lindholm : >> >> 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 we