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)