Talk:Key:lit

Near ambient lighting

See also topic #Level of lighting

For some footways without their own lighting fixtures but with plenty of light from a nearby motorway or other major road, I'm somewhat undecided which way to tag this; they're not dark/unlit but neither are they well lit... Likewise some footways near residential buildings are in a way lit by the staircase signs, but appear quite dark. In rural areas the distinction is often clear enough but I do most of my mapping in urban areas.

Here the presence of lighting doesn't have legal implications as it might in the UK, so it's mainly added value for the visions of a possible pedestrian routing. Either I'd invent a value, say lit=half for such, or start tagging only explicit lit=no only on the really dark ways or areas. The latter leaves some uncertainty for data users, which can't be good. Alv 13:15, 23 March 2009 (UTC)

I would say that lit=no is for only footways and roads that explicitly needs to be marked as unlit, i.e. in an area where you would expect lights, but are none. Untagged roads indicates no information or information not of importance. Your footways that are lit by nearby roads and such is an example of what I would call untagged, while a bend of the road going through a grove making the way completely dark at night would be lit=no. --Skippern 11:10, 24 April 2009 (UTC)

I'm adding lit=* on virtually anything with highway=*, so I've ended up separating the perceived lighting from the technical "lighting is present". A footway that has light fixtures present (and in use) is lit=yes, but can be marked with lit:perceived=poor or lit:perceived=minimal - I haven't yet made up my mind about the values. And as to the footway with motorway lighting, I consider that the light fixtures are designed to, and succeed in lighting up the footway, too - it is therefore lit. That then be lit:perceived=colourless or similar. For park footway lighting fixtures the effective distance is so much smaller that some footway segments, the ones that don't have their own light posts, are lit=no even with lit:perceived=minimal. Alv 17:02, 20 October 2009 (UTC)

+1 for adding lit=yes to objects that are lit – as the tag name tells – no matter whether lamps are on that very object or some nearby object. Instead of lit:perceived=poor etc to tag how bright the objects appear, I'd strongly prefer lit=poor etc. mainly because IMHO it does not make sense to tag lit=no but lit:perceived=minimal, and also because for so few values, it is IMHO not worth to have 2 tags. --Schoschi (talk) 18:08, 20 November 2022 (UTC)

In lighting terms, inadvertent lighting is known as spill (i.e. spilling light). So you might think about using lit=spill where a feature is lit, but only inadvertently and not intentionally. --Zcapw15 (talk) 07:28, 12 July 2014 (UTC)

Ambient light is not a valid reason to tag an object as lit. it requires specific lighting placed specifically for that object. Lampposts directly next to roads or paths & flood lights for sports pitches etc. The example given in the photo here: https://wiki.openstreetmap.org/wiki/Key:lit#Seasonally_changing_situation should be tagged as lit=no.--DaveF63 (talk) 13:01, 20 August 2024 (UTC)

Level of lighting

See also topic #Near ambient lighting

I have a little strugle mapping this key:lit because if yes or no sometimes depends on why you want to know it is lit. Because I have a lot of streets around in my neighborhood with street lamps but those are in very huge distances to each other (like 500m or the like). So if you are a person who wants to walk home over well lit "save" roads this is not the right one, most of the street is dark, people will not see if you get in trouble and there is much shadow where persons could hide. So that street is probably lit=no. But somehow it is lit, how about light pollution? What if an amateur astronomer likes to watch the sky, if there is a street lamp in 250m distance it's probably way too bright. So I think something like key:lit:strength or key:lit:brightness or key:lit:level values like "slightly" or "low" or something. So some way to tell it is lit but not very well :D. The alternative would be to split the street in short parts and set lit=yes around the street lamps (maybe 20m-50m around) and the rest lit=no -- Deus Figendi (talk) 19:41, 9 December 2017 (UTC)

In such situation one may split road in parts, with intermittent lit=yes and lit=no segments Mateusz Konieczny (talk) 10:13, 6 July 2019 (UTC)

Difficult. Where do you split the ways? With long paths, you then split them up into many short ways. How about lit=partial instead?--OSMRogerWilco (talk) 08:34, 17 May 2022 (UTC)

"Where do you split the ways" where way is changing between lit and unlit. "you then split them up into many short ways" - yes, the same as with surface or lane count or turn lanes or hiking routes. "How about lit=partial instead" - it is just basically impossible to use when trying to actually use osm data Mateusz Konieczny (talk) 14:11, 17 May 2022 (UTC)

"where war is lit/unlit" That's the point, it's hard to say. So it is guesswork. "yes, the same as with surface or lane count or turn lanes or hiking routes." For that I also split ways. Now further splits are added by lit. Is this still KISS? What benefit does this have over a Tag like lit=partial? "it is just basically impossible to use when trying to actually use osm data" Why not? You can then differentiate with lit in exactly the same way as with surface. A data user can then decide whether or not to use poorly lit paths. Your solution pretends that there are sections of the path that are not illuminated at all. However, it makes a considerable difference whether you can recognise the course of the path because there is a lantern every x m, even if the light is not sufficient to illuminate the ground sufficiently. --OSMRogerWilco (talk) 14:36, 17 May 2022 (UTC)

See section below for example why lit=limited is hard to interpret, light may be limited in various ways Mateusz Konieczny (talk) 08:53, 18 May 2022 (UTC)

You're right. That's why I suggest not to use lit=limited. ;-) lit=partial is clearer, I think. It is currently used 40 times, but I am open to alternative values. --OSMRogerWilco (talk) 09:43, 18 May 2022 (UTC)

Alternatively, we use namespaces to differ between time and area, such as lit:time=* and lit:area=*. --OSMRogerWilco (talk) 09:58, 18 May 2022 (UTC)

""Where do you split the ways" where war is lit/unlit." Sorry, User:Mateusz Konieczny, but I do not understand the meaning of "war" in this context, which lemma do you refer?

I have the impression that the question "where to draw the line between lit and unlit" is so difficult to answer in an acceptable verifiabile way – in contarst to e.g. lanes or surfaces change – and splitting a long way every 20m makes handling in tools like e.g. StreetComplete a nightmare, so I strongly favor one long way with lit:perceived=poor or related. --Schoschi (talk) 18:08, 20 November 2022 (UTC)

@Schoschi: I fixed my phrasing Mateusz Konieczny (talk) 14:34, 16 June 2023 (UTC)

lit=limited - inconsistent description

In Germany, streets and paths that are not illuminated all night are tagged with lit=limited. Such street lamps are marked with traffic sign 394 in Germany. This has been documented in the german Wiki since 2011: https://wiki.openstreetmap.org/wiki/DE:Key:lit#Laternenring --OSMRogerWilco (talk) 07:05, 16 May 2022 (UTC)

maybe not the best choice of a tag, as it could easily be mistaken for a partially lit street, i.e. with some lighting which isn’t sufficient to illuminate all the surface—-Dieterdreist (talk) 07:57, 16 May 2022 (UTC)

lit=interval is similarly confusing. It doesn't look like for flashing. --- Kovposch (talk) 08:56, 17 May 2022 (UTC)

Automatische Vergabe

An einigen Autobahnen habe ich folgende Note gefunden: "Key lit (Straßenbeleuchtung vorhanden) wurde automatisch vergeben. Sollte eine Straße fälschlicherweise getaggt worden sein, bitte NICHT den Key löschen sondern NUR die Value entsprechend verändern. Probleme bitte bei ChristianW / [1] melden. #(Eine Nummer)"

Christian, vielleicht magst Du Dich dazu mal äußern? Lulu-Ann

"24h" -> "24/7"

Resolved: Changed it. Thanks! --Lulu-Ann 10:14, 17 August 2009 (UTC)

I suggest exchanging the value "24h" with "24/7". opening_hours supports this as a value, so it would become just a special case of lit=operating times and could be handled by a generic opening_hours parser. The current documentation allows both "24h" and "24/7" (the latter being one example for an operating times value) and having two different values for the same thing isn't the best option. --Tordanik 16:05, 16 August 2009 (UTC)

lit values

At the moment there is only a few use of values other than yes or no, so it is possible to improve the values. Please tell me what you think about the following lit values proposal:--Vsandre 12:02, 31 August 2009 (UTC)

lit=yes: At night (unknown time schedule or daylight detection)

lit:times=* The time when the lights are on, using opening_hours

lit:times=24/7 For night and day lights e.g. in tunnels

lit:times=limited If the exact time schedule is unkown but the lights do not work all the night. In Germany there exists a specal traffic sign to mark such street lights:

lit=automatic: When someone enters the way the lights are turned on.

lit=call or lit=sms: to save money, the lights are normally off, but you can call a phone number or write a SMS to switch them on.

lit=disused: There are lights installed, but never used.

lit=no: There are no lights installed

---

A First question: Should we exclude the daytime in the opening_hours-scheme? The problem is that many street lights switch on in the dusk and switch of at a given time and the other way in the morning. I would prefer if we include the daytime and start in the morning and end up in the night.--Vsandre 12:09, 31 August 2009 (UTC)

I don't understand the "first question", though. Could you rephrase it a bit or maybe offer an example? --Tordanik 11:19, 1 September 2009 (UTC)

;-) I will try it. Example:

lights switch on at 5 o'clock am and switch off 30 minutes after sunrise

in the evening they switch on 30 minutes before sunset and switch of at 10 o'clock pm.

Should it be tagged with lit:times=05:00-22:00 or anything else?--Vsandre 12:36, 1 September 2009 (UTC)

Ok, it think I get it. Though there are actually two relevant questions here, imo:

1. multiple intervals: I'd try to tag these interals separately, e.g. lit:times=05:00-08:30, 19:30-22:00. This is already possible with opening_hours, after all. If you don't tag them separately, you would need a way to combine an opening_hours value with "limited"
2. sunrise/sunset and similar values: These cannot currently be expressed by opening_hours, but should be. There are real opening_hours which depend on them, it's not just relevant for lights. --Tordanik 15:53, 1 September 2009 (UTC)

Some comments about the proposed tags:

• The lit:times key is listed below lit=yes. I assume it can be used for lit=automatic, too, to describe lights that will only switch on automatically during certain times of the day?
• Wouldn't it make more sense to choose a general term for "on demand" lights and a sub-key to differentiate between call, sms, web, buttons and so on?

--Tordanik 11:19, 1 September 2009 (UTC)

• lit:times=* is listed below lit:yes=* because this is the main use case and lit=automatic are often combined with a daylight sensor. But if you want to explicitly describe the service times, why not.
• lit=on_demand would be OK or me. But it would be nice if a software can differ between such methods.

--Vsandre 12:36, 1 September 2009 (UTC)

• What about a indication of the color, like lit=white, lit=yellow, lit=orange, in order to give an idea of the bulb used to lighten the object? HB9DTX 29 octobre 2009

  While it's nice information to have, I'd advocate using a separate key for that: lit:color=*. Light quality is a bit more complex phenomenon than a single color, but it's easiest for mappers that way; see also my comment at the about lit:perceived=*. Alv 08:06, 29 October 2009 (UTC)

I also advocate a separate key, otherwise we'd be unable to tag color and time for the same object. --Tordanik 17:35, 29 October 2009 (UTC)

lit=disused: would be useful in the UK, where there are some roads with streetlamps, which have subsequently been switched off to save energy/costs.

• What about specification of the light source values like highway=motorway or highway=tertiary or highway=pedestrian or highway=footway or highway=path.
• What about specification of the light intensity or distance or possible calculation of the intensity and distance. Something like ratio of tens of meters and intensity levels. Situation when cycloway is lit by lights from highway can mean that the light can vary depending on the distance of path or cycloway from the road. Which may lead to situation, that the light is very low or none. This is very relative and depended on distance, but from the map, you can see if the path or footway or cycloway is near to the source of light or not. From the dependency rendering programs could calculate the level of the light or people can make estimation.

Replacing lit_by_gaslight=yes by lit:type=gaslight

I think that the key "lit_by_gaslight" is too special, allowing to indicate only one special type of lamps. Introducing a key for indicating the type of light used for illumination will allow indication of different types of "light production". (I can imagine lit:type=LED...)

The values for "lit:type" should be the same like the ones for "lamp_type" (which should be "lamp:type" in my opinion ... but that's another story). See Tag:highway=street_lamp.

--Ratopi 18:12, 25 June 2012 (BST)

Wall mounted lit

I suppose we can use support=wall_mounted (like Tag:amenity=clock) for this cases. Otourly (talk) 07:14, 7 July 2013 (UTC)

The support=gound and support=pole could also be useful. However, I would see this more as an addition to the man_made=lamp proposal. "lit" is a property of the street, which is not wall-mounted, so it would be weird to tag it that way. --Tordanik 15:41, 7 July 2013 (UTC)

OpenSeaMap/Lights#Exhibition_Conditions

I just want to point out the similarity with "seamark:light:exhibition" which uses some values that might also be useful here: 24h (conflicts with "24/7"), day, fog, night (conflicts with "yes"), warning, storm. --Biff (talk) 00:27, 11 November 2013 (UTC)

"24/7" is part of the opening_hours syntax, so I would clearly prefer it over "24h". Not sure about the others. --Tordanik 14:53, 11 November 2013 (UTC)

Why not applicable to an area?

Why can't lit=yes be applied to an area, such as a car park? --Zcapw15 (talk) 21:38, 20 December 2013 (UTC)

"lit=* can be used on nodes, ways, areas or relations." Where do you get the impression that it cannot be used on areas? --Tordanik 17:36, 21 December 2013 (UTC)

For roads - extent of lit after last lampost

I know this should be subject to survey results, but let's say you have aerial imagery where the position of lamp posts is clear. I've recently taken to labeling the way as 'lit' to 20 meters after the last lamp post. Would people generally agree with this as a reasonable tagging in the absence of survey? Thanks for your input. --Ceyockey (talk) 02:54, 4 October 2016 (UTC)

IMHO mapping lit values based on only lamp positions is not sufficiently accurate. For example: Lamps vary in brightness & angle of emission and height of installation, so some may light up 100m away while others don't even reach 20m far. Objects like trees might block the light causing unlit parts within the lamp range. --Schoschi (talk) 17:10, 20 November 2022 (UTC)

For town for cities with lighting plans to reduce light pollution

The excessive use of public outdoor lighting leads to light pollution, which has side-effects on humans, on wildlife, and is a waste of energy, and money.
Many cities improve their lighting equipments and adopt lighting plan to reduce outdoor public lighting in the middle of the night.

• You can refer to darksky site for a global understanding of this issue.
• In some countries, we can find non-profit organisations doing awareness campaigns, and performing inventory of public policies on this concern, etc. :
  • For example in France, we have ANPCEN.
  • What about other countries ?

To face the general issue of light pollution, many cities choose to perform extinction in the middle of the night of their public lighting.

• Their extinction plan can be something like (by using the opening_hours schema) : Su-Th 00:00-06:00 ; Fri-Sa 01:00-06:00, meaning the extinction of public lightning starts at 00:100 am and until 00:600 am on Friday and Saturdays nights, but starts at midnight and until 06:00 am the rest of the week.
• Moreover the extinction of the public lighting does not always cover the whole territory of the city for local reasons (for example, tourism or safety reason along a high-traffic road); sometimes it covers only 70%. Added to that, the extinction of the public lighting never covers the private properties : private housing development/estates choose by themselves their lighting policies.

Road sign :

• In France, a specific road sign informs drivers that the policy of "night-time extinction of public lighting" has been chosen. You can see it at the entrance of agglomeration.
• What about other countries ?

So this section to see if it is worth doing that into OSM , and if yes how this could be map into OSM ?

• If it is worth it, one proposal would be to :
  • Use the lit key, with a specific value for example lit=extinction_policy
  • Add the extinction hours using the opening_hours schema on a new key for example extinction_policy, so that it could take this form : extinction_policy=Su-Th 00:00-06:00 ; Fri-Sa 01:00-06:00
  • Add the percentage of the territory concerned using a new key for example extinction_surface, so that it could take this form : extinction_surface=70 to tell it covers 70% of the territory.
  • And these information could be added on the place nodes.
    
  • We can suppose their are simpler way, or more compact or more standard way of doing this, any comments welcome !
    
  • To summarize this proposal, we could have something like :
    

place=village

name=MyVillage

lit=extinction_policy

extinction_policy=Su-Th 00:00-06:00 ; Fri-Sa 01:00-06:00

extinction_surface=70

• If it is not worth it in OSM, where else ? wikidata has no property for that yet...

Thank you !
Barnes38 (talk) 13:10, 7 May 2017 (UTC)

For individual roads or other features, this information can already be mapped using lit=operating times as documented here. So if I understand you correctly, your idea is to tag policies that apply to an entire town or city? --Tordanik 13:56, 7 May 2017 (UTC)

In my local area street lighting is activated by light levels - they come on with a dark storm for example. Light reduction I think is done by turning off a few lights - say 1 in 4 lights are turned off. This is done as a cost cutting measure. I am not certain of the timing .. if it is over a fixed time, I think it is done that way during hours where there are few people about. Warin61 (talk) 21:35, 7 May 2017 (UTC)

Yes, this is a political decision at the municipality level, often after conciliation and consultation periods with inhabitants, and after trial period, to apply on the entire town or city a lighting reduction schema, and to adopt a night extinction of public lighting. As far as I know, this is more common in villages and small towns and rural cities. Therefore instead of deciding to light-on from X to Y, they decide to light-off from X to Y, (and by default all the remaining time is light-on). What is important is to store that there were a political decision for green concerns (global warning, reduce the human footprint on ecosystems, etc.) at the city or town level. Barnes38 (talk) 07:36, 8 May 2017 (UTC)

Big cities are rather finding solutions with smart lighting equipments (low consumption systems with LED, presence detectors so that light is on only if somebody is around, automatic switch on/off depending on light levels, ..), but the above proposal related to 'night extinction of public lighting for a whole place' does not address these kinds of solution. Barnes38 (talk) 07:36, 8 May 2017 (UTC)

Some states in the United States have applicable laws , but most state laws won't translate into this granular level of tagging.

Recently, I did look at International Dark Sky Association's Model Lighting Ordinance for my local municipality (it is US-centric). That model ordinance restricts maximum amounts of light to be used by a private property. By ordinance, the government forces private business to dim or turn off their parking lot lights an hour after closing time. It is a model ordinance, so almost no municipality would adopt it without changes. I think there could be too much nuance in laws that might make it hard to document and keep up the date updated on OSM. I do like the idea of trying to internationally map night pollution laws.

For the term "extinction", you might consider the term "light curfew" instead, which is used in that Model Lighting Ordinance. (Curfew normally applies to people not being allowed outside during certain hours.) -- Micahcochran (talk) 17:30, 11 May 2017 (UTC)

The idea is to inventory the municipalities having such lighting ordinances, and how these municipalities have adapted the model for their local needs. The data model proposed above cannot describe such a US lighting ordinance ? Barnes38 (talk) 16:32, 14 May 2017 (UTC)

The "curfew" generally speaking is more for safety or military contexts, and as you said more to restrict people... "Light curfew" keeps quite a lot the idea of a "curfew", so maybe not so good, even if we can understand the idea. Let's keep it open so far... Thanks!! Barnes38 (talk) 16:32, 14 May 2017 (UTC)

I'd suggest not to use a new tag here. We already have the established ':conditional' syntax for features that are not available at all times. As an example: Lights that get switched off after midnight: lit:conditional = yes; no @ Mo-Su 00:00-05:00 --Mueschel (talk) 11:02, 4 October 2018 (UTC)

After various exchanges on the list osm-talk.fr, the proposal changes the following way (as it appears better to scope 'extinction_policy' with 'lit', so that other policies could be described as well).

• place=village
• name=MyVillage
• lit:extinction_policy=yes
• lit:extinction_hours=Su-Th 00:00-06:00 ; Fri-Sa 01:00-06:00
• lit:extinction_surface=70

Other lightning policies could be : "lit:dimmer" or "lit:automatic" in case of smart lightning equipments able to reduce their power or to automatically switch off/on when necessary. Barnes38 (talk) 19:38, 28 July 2017 (UTC)

Separate key to mean that the light is installed

Being lit and having light installed are orthogonal to each other. These examples are from very central streets in highly urbanized areas in Italy, so not in the middle of nowhere.

• A residential street segment is very intensively lit by the lights of the nearby shops and houses, but has no public illumination.
• Street furniture lacks an own lightbulb and is very well lit by a nearby public lighting pole. For example a bench.
• A residential street with lighting poles, which are so weak and distant to each other that you can't see the ground where you put your feet and so I'd rather like to tag lit=no.
• A street furniture object has its own light stupidly placed beyond a shelter panel or other obstruction, and so de facto it's not lit enough for me to comfortably say yes.

So lit should only mean This is lit and there should be a separate tag for This has its own and working lighting infrastructure. To confirm that this is the most reasonable interpretation, StreetComplete adds lit=yes/no to answer Is this object lit? regardless that the light comes from its own infrastructure or a nearby source (even though technically it's a bug).

in particular, the documentation for lit=yes, lit=no, lit=limited should point to another tag to describe that the light is/is not installed.

--Opk12 (talk) 15:55, 11 March 2023 (UTC)

Example 4 shows the difficulty, because a light can be installed elsewhere, yet still be for that thing. --- Kovposch (talk) 15:04, 17 June 2023 (UTC)

Installed together

luminous=* --- Kovposch (talk) 15:28, 16 June 2023 (UTC)

Unrelated - a bench or road does not emit light (the backrest or asphalt is not a LED). luminous=* goes on a lightbulb, if we mapped them. --Opk12 (talk) 21:41, 16 June 2023 (UTC)

By this logic, only electronic display (excluding e-ink) and neon signs can use luminous=yes which excludes all signs using indirect spotlights shining on the board. This isn't provided for in "advertising device is luminous, i.e. if it emits some light.", let alone your mention of the light_source=* itself. Is there any philosophical difference between light attached to a board, and lights built on a road?
-- Kovposch (talk) 15:01, 17 June 2023 (UTC)

Please help keep this section focused. the issue = lit conflates "gets light" and "has possibly ineffective lights". luminous = makes light. your example is lit and not luminous. --Opk12 (talk) 18:01, 19 June 2023 (UTC)

Very nice of you to mark other's comments as irrelevant. Where do you see a definition for advertising=* needing to have direct lighting to be luminous=yes ? They are not defined. As I said, light_source=* exist if it emits light. Besides, advertising=screen is mostly implied to be illuminating.
Your title and lede are about lights being installed, not "has possibly ineffective lights". By that logic, you are also off-topic with that. --- Kovposch (talk) 05:41, 20 June 2023 (UTC)

Who's trolling by hiding and deleting other's comments. I already pointed out the more common alternative to "makes light" is light_source=* , which is described as "light emitting object", not strictly lights only. Neon signs are called neon lights in the first place. And lightbox is a standard term for those boards.
By the same perspective, you can say the usage of lit=* on advertising=* reflects the same problem in not differentiating ambient and direct lighting. So there is an arbitrary distinction between signs with indirect spotlights, and backlights. A sign may further have both spotlights and backlights. https://www.prosign.com.my/showproducts/productid/4068034/cid/417364/polycarbonate-sticker-base-eg-box-up-led-backlit-signage-spotlight-the-diver039s-den-pj-2016
You say the object itself is not a light, and doesn't emit light. But a advertising=board with backlight is the same. The surface panel itself doesn't emit light, only the lights behind does. If there are groundlights or downlights installed on a road or chair, does it count? It's direct lighting. It's even not blocked by the panels of a board.
Examples to consider:

1. https://www.gineicolighting.com.au/product/panca-bench-and-light/
2. https://www.archiexpo.com/prod/urbastyle/product-87178-1974307.html
3. https://www.archiexpo.com/prod/setga/product-126213-2231096.html
4. https://www.barchefs.com/productslight-up-led-park-bench-60.html https://letspartysalinas.com/rental/led-lighted-park-benches/ https://over21partyrentals.com/product/led-park-bench-rental/
5. https://www.overstock.com/Home-Garden/57-Dynamic-Illuminations-Park-Bench-with-Multi-Function-LED-Lights-57-in/36066878/product.html https://www.lichtbankobjekte.com/our-products/ https://www.lichtbankobjekte.com/image-gallery/

Must you sit on the LED for it to qualify?/
--- Kovposch (talk) 08:48, 21 June 2023 (UTC)

Oh, and you haven't addressed any of my examples of benches. Are they not relevant to the discussion? All the examples are direct lighting towards the ground or surrounding, not reflected. For examples 1 to 3, the case of not illuminating the bench seats can be discussed. --- Kovposch (talk) 05:44, 22 June 2023 (UTC)

Not intended lighting

Is lit=yes applying also to footway strongly lit (like by purpose built dedicated lights) but where light source is not intentional? For example when lights were built to lit carriageway or light is emitted by building or by billboard lights.

I think that answer is yes, but some in https://github.com/organicmaps/organicmaps/issues/5327 has doubts, so I want to ask before documenting it.

Is it OK to apply lit=yes to footway in cases for example like https://www.researchgate.net/figure/View-of-a-very-bright-billboards-at-night_fig9_271291168 https://www.freepik.com/premium-photo/billboard-night-with-light-it_43702773.htm ? Mateusz Konieczny (talk) 14:32, 16 June 2023 (UTC)

Due to no responses I documented existing consensus on the lip page. As I understand this, it is not redefining existing tagging but clarifying how this tag is used. Changes is in https://wiki.openstreetmap.org/w/index.php?title=Key%3Alit&type=revision&diff=2546065&oldid=2506067 Mateusz Konieczny (talk) 16:24, 22 June 2023 (UTC)