Proposal talk:Key:light source

These tags would be really helpful to use for ways, or way relations, not only for individual nodes/lamps. So the text at [Proposed_features/Key:light_source#Description]] would read "device, or series of devices", where it currently says "device", or something similar. Abbafei (talk) 13:56, 11 June 2014 (UTC)

So you mean something like natural=tree_row? Sounds reasonable. MHohmann (talk) 19:59, 3 November 2014 (UTC)

Mounted?

How about a tag of light:mount=* with common values of pole, ground, wall? --Jaggedmind (talk) 14:38, 6 August 2014 (UTC)

There exists a key support=* for exactly this purpose, which is used already for other objects, such as amenity=clock. I suggest using this for lamps as well, for the sake of uniformity. MHohmann (talk) 19:59, 3 November 2014 (UTC)

Some comments

light:power=* and light:flux=* only make sense as a total value for the identified map object, and not per lantern or per light bulb.

I suggest support=wire should be support=catenary, which is the correct term where the support wire is stretched between two or more attachment points. You might consider also having support=pendant where the support wire has just a single attachment point vertically above the lantern (if you think there are enough use cases to justify).

light:count=* - need to be clearer if this is a count of light_source=* (such as lanterns, floodlights) or a count of light bulbs, flames, mantles, etc. I don't think it makes sense to count light bulbs, flames, mantles in a single lantern, and light:count=* should be a count of light_source=* (lanterns, floodlights, etc). Hence light:flames=* should be dropped as it doesn't make sense separately from light:count=*.

Zcapw15 (talk) 16:47, 16 August 2015 (UTC)

Primary tag values

No idea of what these are meant to describe at present. I would suggest that it simply describe the lights projected pattern - taking over the role of light:shape ... the values then become much clearer e.g. floodlight, spotlight, spherical (a point source), cylindrical (omnidirectional). The term 'lantern' is not a good chice for a description - has multiple interpretations. Warin61 (talk) 22:57, 18 September 2016 (UTC)

It seems to simply be a categorization of light source types, mostly based on purpose. I think that kind of classification is helpful, as it's usually tricky to describe all the details of a lighting setup with subtags. But we know what a floodlight in a stadium typically looks like, for example.--Tordanik 16:42, 6 October 2017 (UTC)

Still I miss a category like spotlight and indirect illumination (bands), that got rather popular recently.

'spotlight' sounds good to me, but I'm no native English speaker.

The other is much more tricky, since a sufficient solution for indirect lightning would really allow for light bands and luminescent areas. Therefore date consumers should expect light_source=* forming ways and even areas, likely in combination with a value like light_source=indirect.

---Hasienda (talk) 19:34, 3 June 2024 (UTC)

Casing

light:method=LED - Light emitting diode.

It should be led (or then you should write LASER too).

Lower case is easier to type and leds are now an usual term. Like laser it's an abbreviation.

Not a big deal (for German-speakers: das ist mir Käse, yes case :-D)) but for coherence it should be the same casing.

--Nospam2005 (talk) 20:49, 12 July 2017 (UTC)

status

Maybe it is time to go through RfC or maybe also voting? Or is it intended to be kept in permanent "Proposed" stage? Mateusz Konieczny (talk) 05:09, 10 April 2018 (UTC)

Any update on a timeline for progressing this proposal? --Dónal (talk) 23:23, 27 August 2020 (UTC)

Questions.

Hi there,

1. As a general comment, it would be really nice to see the primary tag be light=*, but it seems that the key redirects to the seamark project even though it is not explicitly mentioned, and then we would have to think of what is going to happen to the 2,205 existing objects (according to Taginfo) with the key.
2. If light=* becomes the primary key, we could then make light:source=* refer to the type of light (instead of the potentially unclear light:method=*).
3. In any case, there is a need for a tag that will allow me to describe the model of the street light (e.g. Philips MA60): for consistency reasons, I suggest light:model=* instead of lantern=*.
4. As for the lamp type, the common abbreviations for low and high pressure sodium lamps are SOX and SON respectively. I feel that the abbreviations could be used for sake of simplicity (e.g. light:source=SOX and light:source=SON). Point withdrawn for being potentially confusing.
5. I think we may need to review how we tag solar-powered lamps, because they may not always use LEDs.
6. Due to the widespread use of such a routine on street lights (regarding light:lit=*), it could be mentioned for data users that all lights should be assumed to be light:lit=dusk-dawn, unless defined otherwise.
7. Finally, in many countries, there are light towers that act as street lights (such as the CU Phsoco P655). I think there could be separate tag for that, perhaps light_source=high_mast or light=high_mast?

In conclusion, the current tagging scheme for the street lights are a total mess: for example, the current scheme for lamp_type=* does not distinguish between low and high pressure lighting, for which I have to improvise. I agree that it needs fixing.

Best, --Ika-chan! (talk) 00:31, 18 February 2019 (UTC)

Especially for differentiation of lamp_type=* or the newer and more generic light:methods=* values should be considered like already recommended for street_lamp=*. ---Hasienda (talk) 19:34, 3 June 2024 (UTC)

Space-separated units

The general recommendation for units in OSM (see Map Features/Units) is to insert a space between the number and the unit. Would anyone mind if I apply this to the examples listed on this proposal page? This would mean, for example, changing light:colour=560nm to light:colour=560 nm. --Tordanik 22:35, 11 November 2019 (UTC)

Tagging light distribution for LED lamps

Since light_source=* aims at the same and a lot more instances of light sources, the question at street_lamp discussion wiki page applies here as well:

In current values I cannot see a solution for some modern LED light sources that are mounted in light bulb mimic or on spherical structures and upside-down - at a ceiling that is both roof and top deflector. I argue, that light:shape=directed is rather generic and I'd expect something like light:direction=* for values and/or ranges to elaborate on it.

I see a lot of LED lamps mounted (almost) top-down, so I'd rather use
light:tilt=-90
light:shape=semicircular This light distribution shape is an undefined, new value, but reflects the limited, diffuse light distribution quite good. Btw, 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?

---Hasienda (talk) 14:17, 3 June 2024 (UTC)

Underground bottom-up lighting

'highway=street_lamp' discussion wiki page it has been suggested that ground-based light_sources out of focus and a suitable 'light_source' value should be established.

A related open question was about support=ground being unsuitable and something like support=underground would be more appropriate for lights mounted below surface so that the protection is mounted flush with ground level.

---Hasienda (talk) 19:34, 3 June 2024 (UTC)

See my (new) comment on the 'highway=street_lamp' talk page. In short: I would use support=ground now (for the sake of simplicity and although the definition on support=* speaks of objects on the ground – perhaps this could be changed a little?) + light_source=* with a new value like light_source=in_ground (or simply light_source=ground? – this value is currently used 39x). Thinking further: then you might as well just leave out support=ground, which avoids the problem of its current definition. And you could also add light:tilt=90 to explicitly state that the light is emitted vertically upwards (or in another angle). --Goodidea (talk) 16:06, 27 October 2024 (UTC)