Talk:Tag:highway=street lamp

From OpenStreetMap Wiki
Jump to navigation Jump to search

Gas Lighting

The estate of The Park in Nottingham is also exclusively lit by gas. It might help to work through the Dusseldorf tagging so that it is usable in the Park. I have only tagged the roads, but do have waypoints & pictures of one or two gas lights. SK53 17:59, 7 May 2011 (BST)

Roads only?

Is this tag intended only for structures and devices that provide light for roads or streets? The definition is very narrow and seems to exclude all other targets of illumination such as sports fields or industrial facilities. Furthermore, the tag is literally required to be "on the edge of a road". Is there any justification to exclude structures that are in the middle of a divided road or further to the side? What about lamps suspended above the road? --T99 18:47, 27 May 2011 (BST)

A street lamp is a street lamp no matter what someone wrote in this wiki. The usage matters. Alv 10:27, 28 May 2011 (BST)

Serial numbers

Each lamp has a serial number attached to its pole... Which is very important when reporting incident locations etc. ! So be sure to enter it somehow... Jidanni (talk) 13:23, 20 May 2013 (UTC)

ref=* works fine. Alv (talk) 15:52, 20 May 2013 (UTC)
Should lamp_ref_swd=*, which is specaily only for Stadtwerke Düsseldorf (Germany), then be removed from the entry and ref=* added? --ChrissW-R1 (talk) 17:11, 10 May 2014 (UTC)

So what tag should be used for the serial number, when the serial number is not used for navigation? Doesn't seem to make sense to use anything other than ref=* - the current definition of ref=* is too strict. In the UK, the number is only used for reporting lighting faults, not for navigation. Zcapw15 (talk) 21:39, 8 January 2015 (UTC)

OK what about when we get the file from the government, and each pole has two numbers. One that is the same as seen on the pole, and the other some sort of extra number. Should the one on the pole be "name" and the other be "ref"? Jidanni (talk) 02:29, 22 July 2017 (UTC)

The city of Augsburg, Germany for example also has two numbers per pole. As I am being told, their poles have a low-hanging number, the pole ID, and a high-hanging number, a bulb ID. The bulb ID is unique, the pole ID is not unique, and the 2-tuple (street, pole) is unique again. (Unique for a given operator=, naturally.) Secondly, in case of Göttingen, Germany and nearby settlings, only the poles are numbered, and, barring spelling mistakes, are also unique. Therefore, I suggest you consult with your local authority for inquiring which numbers mean what. Now, in OSM, what is mapped is poles; bulbs are merely noted down with the "light:count" attribute. This indeed makes it a bit awkward to set an appropriate ref= for Augsburg lamps given the uniqueness characteristics described earlier. So my self-suggestion is to just note down the refs somehow first ("ref:pole"=12, "ref:light"="34;56"), and over time figure out what to do with "ref" (maybe synthesize and incoroporating an abbreviation of the street name). Jengelh (talk) 07:51, 24 July 2017 (UTC)

Indeed often one sees two numbers. A bigger one which turns out to be the old number, and a smaller sticker, which turns out to be the new number. One can guess which one the public will be reading over the phone to the police on misty nights... Jidanni (talk) 03:08, 25 July 2017 (UTC)

Page clean up

I have cleaned up the text on the page a bit to reflect what was discussed in the above 3 topics.

I have also removed the artificial assumption that all street lamps turn on at fixed times of day, adding an informal section explaining how varied this can be without invalidating the tag. Knowing exactly when and how lights are turned on in a given place is not always public knowledge, may be subject to arbitrary administrative changes, and typically will not be mapped.

As part of this clean up I have tried to give practical (easy to map) definitions of exactly what point should get the tag, allowing tagging of either the lamppost (next to the road or elsewhere) or where the lamp is generally focused (typically a node that is also part of the way itself), I hope that matches current practice, otherwise just change the text. Jbohmdk 21:22, 16 September 2013 (UTC)

Cable Suspended Street Lamps

Has anyone got any thoughts about how to tag streetlights which are suspended at intervals from cables running down the street?

This proposal suggests using support=wire. --Tordanik 13:13, 11 May 2015 (UTC)

Positioning

I was looking in this page to find out whether to place the lamp node next to or on the way that it lights.

I did find it under Tagging, which I didn't expect: "Either the point on the road that the lamp points to (below the lamp is the light is straight down), or the point on the ground where the light pole stands."

I propose moving this to another section "Positioning" above Tagging.

I would like to know the answer to which position is best before making that change, though. Can someone tell me? I assume it's easier for supporting applications to associate the lamp with the street if they share the node. -- Hubne (talk) 03:38, 29 June 2015 (UTC)

I would clearly prefer the actual position of the lamp here, and was not aware that there is even an alternative. I'm also under the impression that most renderings place the lamps (or lamp icons) where the node is, and would therefore break if the "point on the road" interpretation was used. --Tordanik 11:32, 29 June 2015 (UTC)
So there's a conflict between renderers which perform best with a disjoined node, and "intelligent applications" which benefit from a tighter relationship in the data itself. It's difficult to choose.
For my current situation, given that I already have lit=yes on the way, this is enough for any "intelligent applications" that I can imagine existing now to behave correctly. So I will separate the node in this instance. The uncertainty does not encourage me to map more of these though. -- Hubne (talk) 05:40, 30 June 2015 (UTC)
I have added the Positioning section and summarised some of these points on the page. -- Hubne (talk) 06:04, 30 June 2015 (UTC)
And I've done a bit of counting with a script. It seems that placing the lamps next to the road is clearly favoured by mappers (plus much more sensible, imo), so I have rewritten the section. --Tordanik 17:14, 10 July 2015 (UTC)

Currently we see 

 Add the node where the light source is actually positioned (i.e. next to the way lit).

OK, then add "And not the location of the base of the pole from which the light is suspended." Better yet, have a sub tag where one can say if the location is the base of the pole, or the point on the surface of the earth directly below the light. P.S., one pole may have two or more lights... so need another subtag to count them if uploading pole positions. Anyway for me I want to actually upload light poles, not lights. Jidanni (talk) 02:36, 22 July 2017 (UTC)

And 

(i.e. next to the way lit).

that is usually where the pole is. The light is above the way being lit. Jidanni (talk) 02:37, 22 July 2017 (UTC)

Well, the place where the pole is on the side of the road is still very important. Cars should avoid it 24 hours a day.

Just like cars should avoid electric poles. Jidanni (talk) 12:46, 16 December 2022 (UTC)

Also depending on a satellite's angle, different imagery will have different positions for the lamp fixture. However the base will always be in the same spot! So the base , where the pole meets the street, is easier to map. Plus, one can just follow shadows to the base too. Anyway, all government city topographic maps that I have seen that show street lamps always show the position of the base. But yeah sure, map both of them, the base and the fixture. But I'm still saying the base had better be there in the database for driverless automobile safety, in general landmark locating when walking down the street. (Jim's house is the one with the street lamp in front of it. But if the lamp is in the middle of the road on the map then you can't tell which side Jim's house is.)


Jidanni (talk) 22:48, 16 December 2022 (UTC)

For me it is clearly the base of the lamp (its pole) for placing the node. I didn't expect there would be a discussion about it. But you can have other ideas for almost everything, which is OK. However, putting it where the light falls is not a good idea at all, I think. That would not work even with lamps with one mast and 2 or 3 lamp heads. And I don't think any other variants are a good idea either. Goodidea (talk) 00:24, 30 April 2023 (UTC)

Yeah. If we put the light where it falls (in the middle of the road), one cannot tell which side its post is at... No argument if the light is suspended by wires between two poles I guess. Jidanni (talk) 20:44, 30 August 2023 (UTC)

Disused

How to tag a highway=street_lamp witch is always off (probably to save money), but still clearly visible and usefull as a landmark? --Leptitmouton (talk) 19:01, 1 December 2015 (UTC)

lit=disused seems to be the way, and it seems to be recognised by the ITO streetlamp map. --Zcapw15 (talk) 19:59, 1 December 2015 (UTC)
Great question, though how can you be sure it's not just broken? And you hopefully can monitor for its use changing. It's a still a streetlamp.
Until I saw Zcapw15's response, I was going to suggest adding disused=yes. Putting aside what ITO recognises, I still think this is more elegant for streetlamps. If you look at lit=*, it is for applying to other kinds of objects (tunnels, footways etc). However, the purpose of a streetlamp is illumination, so it should be enough to say say it's disused (and therefore not illuminating). I'm not a fan of unnecessary complication or variation from established generic conventions that work. I guess both can be used until this issue is resolved (if ever). --Hubne (talk) 23:32, 1 December 2015 (UTC)
In my opinion, using lit is incorrect, because that key is for the object the lamp shines on, not the lamp itself. So the main decision is between highway=street_lamp + disused=yes and disused:highway=street_lamp. --Tordanik 10:55, 2 December 2015 (UTC)
disused=yes has the usual problem that data consumers have to explicitly look for it. The "disused:" prefix removes it from rendering. Perhaps "light:lit=none" or "light:lit=no" or "light:lit=off"? Edit: out of these 3, only "light:lit=off" is already used - 140 times. --Richlv (talk) 14:53, 20 October 2020 (UTC)

Light only on streets ?

Other areas are also lit which are not streets : parking lots, stadiums and sport centers, airports/harbors, prisons. Many of them are in private areas accessible to the public, or with interest for the public.

In large areas (larger than most streets, such as stadiums and parkings) these are often over elevated on very high maasts. On pedestrian areas, lighting is frequently directly on the ground near the borders or alleys.

I wonder if "street_lamp=*" is the correct key for generalization of lighting. Of course we can set "support=*" and "heights". But when the supports are very high and support multiple lamps lioghting a large area around, they are extremely visible from far away (they are usually taller than most buildings and trees, sometimes built on top of roofs (common on stadiums with tribunes).

Given that lit=* is used to indicate the objects being exposed to light (and not the lighting system itself and its support) I think we should have other keys notably for the support structure : maast/pole, probably a man_made.

But in all cases using "highway=*" is wrong: it incorrectly mixes the lighting system (even if the structure or support) may vary and the exposed object (here a street, eventually a small pedestrian area).

But I've not found any more generic version for lighting structures. There are only specialized keys for lighthouses (whose purpose is not to lighten an area but send a visual signal and help route), or beacons (sending visual signals to planes, notably in airports/heliports, or over high structures and on high electric wires, to help aerial navigation or signal dangers, but here also not to lighten an area).

Frequently these high structures will support other systems, such as radio-emitters for radio broadcasting, or for telephony, or private communications), notably in stadiums. If there's a lighting system on top of these high structures, they should be tagged in addition to other installed equipments, and probaly also with their own height (which may be lower than the structure itself. In some cases however the light may just be directly on the border of the roof of a high building.

Finally there are lighting spots for monuments generally installed at ground level but not necessarily on the monument itself or permanently installed in outdoor theaters (they are not lit at all time, only during events).

"lit=yes" is not applicable. How can we tag the lighting structures?

I propose a "man_made=light_pole" or light_maast or light_tower... (these could also be found on highways, notably on motorways near intersection links, or over large bridges). But if we use another generic tag for the structure (not dedicated only to light), we need a tag for specifying that it supports a light equipment and the height of its installation (possibly other indicators such as the number of lamps or direction of lighting, or its role: plain lighting, decorative, signaling dangers.

— Verdy_p (talk) 18:11, 11 September 2016 (UTC)

There is now man_made=mast with tower:type=lighting.

— Fleezing (talk) 05:09, 20 April 2022 (UTC)

Direction: all directions

iD editor wants us to add Key:direction. Mention how to tag lights that shine equally in all directions. Like a w:Gat (hat). Jidanni (talk) 05:44, 5 October 2019 (UTC)

Artistic or vanity lights

Mention how to tag artistic or vanity street lights. Electric ones but that look like a w:Gat (hat). Jidanni (talk) 05:48, 5 October 2019 (UTC)

Tagging variations

Mapping street lights attached to man_made=utility_pole, power=pole, telecom=pole doesn't currently have any suggested / supported tagging. I did find a proposal for light_source=* but it hasn't been voted on despite being created in 2014.

However, it looks like the wiki page for power=pole indicates it's fine to just add highway=street_lamp on the node.

Should that be reflected on this page?

--Dónal (talk) 23:28, 27 August 2020 (UTC)

support=wall/wall_mounted: useful?

For support=* the page documents i.a.:

  • wall – Direct attachment to a wall
  • wall_mounted – Attached to a wall by way of a metal bar

First of, those are quite bad values because they are very non-obvious.

But also, is this distinction even useful? —M!dgard [ talk ] 14:34, 9 January 2021 (UTC)

I suspect that those definitions in the wiki do not actually match how the two tags are used. I would guess that both are used to mean "attached to a wall in some way". --Jeisenbe (talk) 02:27, 10 January 2021 (UTC)
It's a distinction that matters to me (for 3d rendering). But if you have ideas for better values (or better documentation) that would be less likely to be confused, I'd welcome that. --Tordanik 08:30, 10 April 2021 (UTC)

Not a street

Does this key include all kinds of lighting implements or only repeating series of lights illuminating a highway?

The image in the info box actually seems to feature lights on a courtyard where no cars may drive (okay, maybe there's a hidden pedestrian highway=footway in there).

What about lights illuminating other things such as sports venues, railyards, harbor docks, electric substations and other industrial facilities?

And what about single lighting towers that do not belong in a repeating sequence?

-- T99 (talk) 10:14, 25 December 2021 (UTC)

Yes, what about garden lights, stabbed into the ground by homeowners along pathway edges. They're typically solar powered and only provide light for a few hours after sunset. They're typically about a foot high only. They're an important source of light along pathways. Jidanni (talk) 01:35, 19 October 2022 (UTC)

Combination electric pole and Street Lamp

highway=street_lamp
power=pole
ref=4466A;120061618
lamp_type=led
material=wood

Is what I used. I couldn't even tell which number referred to the street lamp, and which referred to the electric pole. I wonder if what I did was correct. Jidanni (talk) 00:12, 16 December 2022 (UTC)

Apologies if this is only tangentially related, but I think I might have brought this up somewhere else, but power poles in my area will often have 3 different references numbers that all refer to different operators/owners of the power pole. I've never figured out a good way to tag that. So I just leave out the shortest 1 or 2 references. I'm not sure just using a semicolon would work either. At the end of the day I'd like for all three operators/owners to have their set of tags so I can search for whichever one I want without having to decipher multiple values in the ref tag. I guess there's no current way to do that though, which is a bummer to say the least. Maybe someone will come up with something though. --Adamant1 (talk) 02:42, 16 December 2022 (UTC)

Maybe "pge=123;xyz=456;abc=789" ?

(By the way my jamming two items into one node shows signs of being a mistake: for instance "material": are we talking about the material of the light, or the electrical pole or what..) Jidanni (talk) 12:52, 16 December 2022 (UTC)

Good call. I guess something like ref:PGE=1234 + ref:local_utility=5678 would work. I worry about tagging creep/fragmentation with things like that though. Which seems to be particularly bad when it comes to prefixes/namespaces. Same goes for "material." Where someone might start out with material:pole=wood + material:street_lamp=metal, which is probably fine, but then it will inevitably descend into a prefix/namespace for every to inches of the pole where the wood grain is in a slightly different direction or whatever. I'm good with that lol. Although I'll probably still start using ref:PGE=1234 + ref:local_utility=5678 regardless since there doesn't seem to be an alternative. --Adamant1 (talk) 04:45, 17 December 2022 (UTC)

bent_mast

bent_mast – The light is at the end of a bent mast

How about "upside-down uppercase L" shaped masts, made of two segments, with nothing bent about them?

Well, in my mind when you say "bent" you're talking about lowercase "r" shaped masts.

Also please mention what parts of the L are the mast and what is the horizontal part called, or maybe they both are the mast.

Jidanni (talk) 12:30, 16 December 2022 (UTC)

I've often asked myself exactly the same thing, mainly because such "upside-down uppercase L" lamps are very common here with me. I actually found the tag "lamp_mount=angled_mast" the most appropriate for this. Because "bent" definitely means a curved shape. But it really depends on the definition of what is to be counted as "mast". If it's the whole structure, not just the "pole", then "angled_mast" would be correct, otherwise not. For the inverted L-shape, it would be a -90° angled mast (often it might be closer to -80°). Unfortunately, however, the notation for "lamp_mount=angled_mast" is narrowed to "wall_mounted" lamps attached to a metal construction pointing 90° from the wall, which I think is not a good (because unnecessary) constraint on this case. Shouldn't that be changed and expanded (with a definition of "mast" for the entire mounting structure of a lamp)? Otherwise you could probably tag such an "upside-down uppercase L" lamp with lamp_mount=straight_mast + lamp:tilt=-90 (if you want to restrict the definition of "mast" to its "pole" and the horizontal part of the "L" is the angled lamp head). I see these two possibilities.
The "bent_mast" type is clearer and easier I think. I only ask myself for example if lamps with a pole whose upper part has a "upside-down uppercase U" shape (lamp:tilt=-90) still fall under the term "bent"? I think yes ... very much bent into a semicircle. I think it would be a good idea to add several example photos of lamps (normal and less normal ones) with tags ... Also for the discussion. Goodidea (talk) 01:13, 30 April 2023 (UTC)

Ground based lights?

Where the lights are based in the ground and shine through glass to illuminate the area ... These could be mapped as an area, height=0, support=ground, lamp_mount=ground ??? Warin61 (talk) 04:49, 29 December 2022 (UTC)

"height=0, support=ground, lamp_mount=ground" seems odd to me since the lights are in the ground. Not on it. So I assume something like that would be height=-1 or whatever, which doesn't make sense. Either way, there's a glass bridge where I live that is lit from underneath. Although it's not currently tagged to indicate that it's lit, I'd probably just go with lit=yes and not worry about the rest. Otherwise, it would be pretty complicated if not impossible to map every individual light source underneath it. --Adamant1 (talk) 19:46, 31 December 2022 (UTC)
The description of support=ground here seems to fit perfectly, doesn't it? “The lamp is in a fixture installed right in the ground (common locations: event venues or parks)”. I wouldn't set height=0, it's redundant. And lamp_mount=ground has 888 usages according to Taginfo, it could perhaps be used, but also a little superflou together with support=ground? And (yet) no documented (described) value in the wiki, in contrast to support=ground. Maybe the term "mount" doesn't quite fit here either. I would probably have a preference for support=ground. Although that usually means “standing directly ON the ground”, not IN the ground (current Wiki definition: "The feature is directly put on the ground."). The definition which is used here doesn't seem to be consistent with the general definition of support=ground (not a good idea in my opinion). support=underground might be more accurate (because the lamp itself is UNDER the surface), but again not a wiki-defined value. There doesn't seem to be a clean solution (yet). Perhaps the best way could be to introduce something like lamp_mount=underground or lamp_mount=in_the_ground (?) and choose an appropriate description for it. For example: “A lamp that is mounted sunk into the ground and is flush with the surface and emits its light upwards.” (I'm not a native English speaker, maybe a better wording is possible). Goodidea (talk) 01:58, 30 April 2023 (UTC)
I don't think this case fits highway=street_lamp, which is described as: "a raised source of light above a road". Maybe this case fits better Key:light_source, of which it could be a value.--Ivanbranco (talk) 14:53, 30 April 2023 (UTC)
I think, I would use support=ground + light_source=* now. The only problem is, that there is no very good value for light_source=* yet. light_source=lantern doesn't fit very well. So maybe you have to invent a new value (ATYL) – e.g. light_source=in_ground (or simply light_source=ground? – this value is currently used 39x). If you google for such lights, you will find the terms 'in-ground light', 'in-ground lamp', 'ground lamp', 'in-ground uplight', 'landscape light' (and others). 'in-ground light' seems to be quite common. But I am not a native English speaker ... --Goodidea (talk) 15:49, 27 October 2024 (UTC)
Both, support=ground and light_source=ground sound to me from meaningless to wrong, I must say. If we are going to map such specific details, then I would prefer more precise tags. light_source=in-ground_uplight sounds very meaningful to me. The question is, should we take all the details into account? In addition to the usual uplights, there are also traversable lights that emit light from the sides to mark streets, paths or driveways. You could set tilt but I would like to have unique tags (values for light_source) to specify these lights. --Chris2map (talk) 18:49, 27 October 2024 (UTC)
No, please don't mix different aspects. In-ground (vs others), and uplight (vs downlight), are separate. These 2 physical aspects can apply to all lights. light_source=* is functional and characteristic.
Uplight is light:tilt=90 . There will be redundancy.
—— Kovposch (talk) 07:29, 28 October 2024 (UTC)
Landscape light is not limited to in-ground uplight. It can describe all small lights used in landscape decoration, which are very different. It may be light_source=lantern as well, or overlapping.
  • I'm surprised there's no light_source=spotlight , when there is already light_source=floodlight . Cf seamark:light:category=*
    • Unfortunately, there is potential ambiguity in "spotlight". Some may think it is raised and angled towards a spot. Or it may be lighting up a particular target.
    • Spotlights are used in different setups. One prominent technique is indirect lighting against the wall (washing, or grazing; special case in scallop; cove lighting can also light up a wall from ceiling). These can be in-ground uplight, ceiling downlight, or wall-mounted (uplight, downlight, or both).
  • Maybe light_source=floor_lighting , to emphasize it's lighting up the floor, or pavement. But "floor lamp" commonly means a lamp standing on the floor.

—— Kovposch (talk) 07:56, 28 October 2024 (UTC)
Be aware there are problems with support=*

—— Kovposch (talk) 07:30, 28 October 2024 (UTC)
To demonstrate here, there are spike lights, for spotlights to be simply inserted into soil on a spike. It could use some clearer *=spike + *=ground . The worse case is still for in-wall vs cantilever arm off wall in the support=wall and support=wall_mounted confusion.
—— Kovposch (talk) 12:04, 28 October 2024 (UTC)
OK, I think I understand your basic idea of the tagging: General tags for each property of a light or lamp, so that those tags can be applied to every source of light. One for the type of lamp body, one for the direction, and one for the location. But I don't quite get that together with some of the current tag values. For me, light_source= lantern/signal_lamp/floor_lighting/in-ground_uplight are on the same level of designation. All of them describe more than just one aspect. I don't insist on the in-ground_uplight tag value. In my opinion, it would just be a clear term that doesn't need much explanation. With the value ground, several additional tags are required to determine the exact type of luminaire; in or on the ground / traversable or not, direction of light.
What would be your prefered tagging of e.g. the in-ground uplights? I guess light_source=spotlight + light:tilt=90 + support=in-ground? --Chris2map (talk) 16:16, 28 October 2024 (UTC)
An in-ground uplight can be direct lighting for the floor / ambience only, or it can be mainly indirect lighting against a wall . Significant difference between them in layout, and functioning.
  • The indirect lighting lights up the wall at the same time, provides softer wider area illumination for the environment, and adds to the aesthetics by showing the wall texture.
  • At a higher level, I'm not sure the effect from their light intensity, but blocking an uplight by indirect lighting reduces light pollution in theory.
To complicate further, spotlights only describe narrower focused point sources. Some in-ground uplight are floodlights. https://www.lightculture.com.au/products/in-ground-floodlight/
For now, maybe light_source=floor_light / light_source=floor_lighting is simpler. It could be more generic, to be applicable for lights at the bottom of a wall, and those at the underside of a stair. They are all mainly for lighting up the floor.
support=in-ground would be acceptable, if support=* has to be used. But as I said, I don't like support=* for the growing confusion.
Looking in general, actually location=surface may be clearer. It could show the vertical level of the light directly. Then we don't have to solve support=* or lamp_mount=* immediately.
If I have to think of something for them, a possible option for support=ground is lamp_mount=recessed (In-ground is also called ground or floor "recessed"; those inside the ceiling are ceiling recessed) / lamp_mount=embedded ( "embedded" seems less common). Or, I can say it's lamp_mount=direct , as nothing is used to mount the light housing. In any case, they could be used together with location=* , so we can start with location=surface .
Side note:
Linear strip lights can be in-ground uplight too https://www.led-linear.com/fileadmin/_processed_/c/c/csm_led-linear-in-ground-indoor_acf5ad472e.jpg https://www.led-linear.com/products/category/in-ground-indoor
Drawing points vs lines may not be sufficient. Some users may want to draw lines for closely-spaced, or long rows of point sources.
—— Kovposch (talk) 14:39, 29 October 2024 (UTC)
If I had to pick some tags among these, I would choose:
light_source=floor_light
lamp_mount=in-ground or lamp_mount=floor_recessed
If one can add more details, light:tilt=* and light:shape=* could be used.
I also don't like the use of support=*. I would add more values to lamp_mount=* to distinguish "on-ground" from "in-ground", and "in-wall" from "on-wall" and with "wall cantilever". --Chris2map (talk) 16:36, 29 October 2024 (UTC)

LED light distribution (shape)

I need a solution for modern LED light source that is mounted upside-down, thus light:shape=spherical doesn't apply. After reading the table of existing values I thought 

light:shape=semispherical combined with light:tilt=-90

will fit nicely. So I went on and mapped a bunch of street lamps, wall_mounted as well as on mast, with these attributes.

? Does anyone have objections against seeing this additional value documented on the wiki page?

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Tag:highway%3Dstreet_lamp&oldid=2771145"