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 asamenity=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 likelight_source=indirect
. - ---Hasienda (talk) 19:34, 3 June 2024 (UTC)
- Still I miss a category like spotlight and indirect illumination (bands), that got rather popular recently.
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)
Questions.
Hi there,
- 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. - If
light=*
becomes the primary key, we could then makelight:source=*
refer to the type of light (instead of the potentially unclearlight:method=*
). - 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 oflantern=*
. 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.Point withdrawn for being potentially confusing.light:source=SOX
andlight:source=SON
).- I think we may need to review how we tag solar-powered lamps, because they may not always use LEDs.
- 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 belight:lit=dusk-dawn
, unless defined otherwise. - 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
orlight=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 genericlight:methods=*
values should be considered like already recommended forstreet_lamp=*
. ---Hasienda (talk) 19:34, 3 June 2024 (UTC)
- Especially for differentiation of
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 onsupport=*
speaks of objects on the ground – perhaps this could be changed a little?) +light_source=*
with a new value likelight_source=in_ground
(or simplylight_source=ground
? – this value is currently used 39x). Thinking further: then you might as well just leave outsupport=ground
, which avoids the problem of its current definition. And you could also addlight:tilt=90
to explicitly state that the light is emitted vertically upwards (or in another angle). --Goodidea (talk) 16:06, 27 October 2024 (UTC)