Talk:Key:lit

Contents 1 Key:lit and rendering/routing 2 lit implies highway? 3 Near ambient lighting 4 Automatische Vergabe 5 "24h" -> "24/7" 6 lit values

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)

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)

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:

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)