Talk:Key:lit

From OpenStreetMap Wiki
Jump to: navigation, search

Key:lit and rendering/routing

For a generic street map this key is of little interest, but theoretically it can be of high interest for special purpose maps and for routing software. For example, it would be preferred to have a route following lit roads in a residential area if unlit roads exists, both for the drivers safety and for the safety of any pedestrians. Same also a special purpose map can be generating highlighting areas where it is unsafe to drive, or whatever might be of interest to the user. The key let us provide the information, and the user can decide whether he want to use it or not. --Skippern 13:49, 7 March 2009 (UTC)

lit implies highway?

I think any object can be lit, also buildings, areas, nodes. I don't think lit=* should imply highway=*. --Lulu-Ann 21:13, 18 March 2009 (UTC)

  • I don't believe it does. It just so happens that the majority of the uses relate to highway objects. Question is - if you have 'lit' related to a building, would you, in fact, indicate 'entrance' as being lit, or the parking area or, for a bank, the ATM? --Ceyockey (talk) 02:50, 4 October 2016 (UTC)

Near ambient 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)

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)

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"

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)

Changed it. Thanks! --Lulu-Ann 10:14, 17 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: german traffic sign 394
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.

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)

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 :

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

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)


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

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)