Proposal talk:Electricity

From OpenStreetMap Wiki
Jump to navigation Jump to search

Comments from Nakaner and Woodpeck

I'll work through the comments from top to bottom - hopefully it's not too disjointed.

  • I can add a further sentence stating that the tag should only be used when it is deemed significant - this seems like a given for any OSM tagging currently, just as not every tree is tagged or the height of every building added. It is not mandatory to use this for every building as suggested in the comments.
  • "No" is clearly the default negative in OSM and keeping the "none" value will only result in further error by future mappers leading to a splitting of two values with the same meaning. I'd rather correct the 1000 "nones"now (or rather just deprecate and wait for them to be fixed) than to carry this error into the future. This change is decidely NOT just for changing.
  • In the same way that tagging private generators also can point to political beliefs of residents. Or the building material. Or any number of thigs. If this is a genuine criticism, then no mapping of any private property should be allowed.
  • The 'origin'of electricity has been exhaustingly discussed. As a physicist, I'm all too clear that electrons aren't distinguishable particles - guarantees of origin are used however and this is a particularly significant tag for charging stations. The financial aspect of this tag is explicitly mentioned in the tagging!
  • For the house in Thüringen, if I wanted to know if my particular hostel uses solar power, I would then have to look at satellite imagery or open JOSM to see if solar panels are there in current tagging conditions. This doesn't allow for filtering or analysis as no connection is made between buildings and generators. This becomes especially hard without the proposed tagging, if the generators are located next to a building and not roof-mounted.
  • The proposal is concerned with the availability of features - conditional requirements can be handeled by conditional restrictions as already done for a schedule. (Also, ICEs are moving objects)
  • As discussed below, adding electricity=yes when using electricity subtags makes it easier for data consumers.
I wonder if a solution to this is to make the top-level tag be amenity=electricity instead of electricity=yes. That would more explicitly describe that we're talking about electricity as an accessible feature and not something that mappers would tag on random houses and so forth. --ZeLonewolf (talk) 02:24, 2 December 2020 (UTC)
    • "just as not every tree is tagged or the height of every building added" - note that not only significant trees are mapped. In some places mappers started mapping every single tree and height of every single building.
    • "It is not mandatory to use this for every building" - but according to proposal it is acceptable to do this. So mapper may add this tag to thousands of buildings in my city (without any value whatsoever) and it would be acceptable according to this proposal. In general, if something is described as mappable people will map it sooner or later. Mateusz Konieczny (talk) 09:49, 2 December 2020 (UTC)
I agree that it is not necessary to map this for every building and, especially in the western world, only useful for public buildings and amenities. However, there also seems to be a clear need to tag electricity availabilty in developing regions and a firefighter also mentioned that this is relevant information for them as the increasing numbers of generators and batteries in households pose a risk for them due to islanding. If you have any good ideas on how to separate these two goals or how to phrase it well, I'm all ears. It would have been helpful, however, if this had come up in the 1.5 months of RFC. - Luke (talk) 16:01, 2 December 2020 (UTC)

power=generator, generator:method, generator:source

Resolved: Proposed tagging is intended for a building/site while power=generator is for devices onlyFanfouer (talk) 22:00, 5 November 2020 (UTC)

Please note that we have the established tags "power=generator, "generator:method" and "generator:source" already, so I think we have appropiate tagging also for human dwellings acutally and I miss to see some profit your proposal brings to change the existing tagging. --Lukas458 (talk) 11:39, 6 May 2020 (UTC)

power=generator + generator=* is clearly for mapping a device that generates the electricity. electricity=* is intended to be put on a building of any purpose to indicate if electricity is available there (could be from a power=generator proper to it or from a distribution grid). Most of the time you won't be able to map a power generator implanted somewhere on people's house but you could ask them if they have electricity available from some source (or you just find it's connected to the grid), for example as part of a data collection project. -- Privatemajory (talk) 18:42, 6 May 2020 (UTC)
Oh yes, you are right, I just misunderstood your proposal. Sorry for this. --Lukas458 (talk) 14:49, 10 June 2020 (UTC)

electricity_source instead of electricity=* ?

Maybe, accordingly to the approved key water_source=*, we should name this key electricity_soure=* as well, if I see it right that is has the same meaning, just for electricty instead of water?--Lukas458 (talk) 16:09, 29 August 2020 (UTC)

I thought of something like that when I was going to make the proposal, then I was pointed to electricity=* which was already used in some parts of the world, just for the purpose. So I decided to push that tag instead of inventing a new one.

Alternately, why not amenity=electricity optionally combined with electricity=*? ZeLonewolf (talk) 23:29, 2 November 2020 (UTC)

Do you mean for tagging electrical outlets? Double-tagging amenities in the case of charging stations, cafes, etc wouldn't be the best. (Also, the above Lukas458, surprisingly, is an entirely different person - although I did check if I accidently had two accounts.) - Luke (talk) 00:33, 3 November 2020 (UTC)

electricity=solar?

At the page Key:electricity there are two more values mentioned: electricity=solar for a feature which is supplied with electricity that is generated by solar panels on the feature, and this has been used about 200 times.

Would you like to approve that value as well, or deprecate it? --Jeisenbe (talk) 21:35, 15 October 2020 (UTC)

I would deprecate this tag (especially as it has mostly been used only in one geographic area) and instead replace it with electricity:origin=solar. I should probably have explained this in more detail, but this was the inconsistency I meant. A charging station, for example, could be connected to a solar generator - do you then use electricity=generator or electricity=solar? Or, for green pricing, it is possible to have combinations such as electricity=grid, electricity:source=hydro, as would be the case in the provided example. These cases wouldn't be accurately mappable given the original proposal. - Luke (talk) 22:17, 15 October 2020 (UTC)
So with this proposal how would we tag, for example, a remote guest cabin which has electricty supplied by solar panels on the roof? --Jeisenbe (talk) 07:48, 17 October 2020 (UTC)
The building outline itself would be tagged with tourism=chalet, electricity=generator, electricity:origin=solar, electricity:access=private and perhaps electricity:fee=customers and other details such as name and so on. This would enable potential guests to filter out only cabins with electricity (and perhaps even more specifically only with solar). The nearby solar panels would be mapped as power=generator and generator:source=solar. - Luke (talk) 11:00, 17 October 2020 (UTC)
Currently electricity=generator seems to mean "this feature has electricity supplied by a portable diesel or gasoline generator", so that would be a re-definition of the tag. It's not very commonly used, so it's not a huge issue, but probably should be mentioned in the proposal page. An option that might be less confusing would be just 4 options: electricity=yes, electricity=no, electricity=grid and electricity=offgrid - the last one could be a diesel generator, or solar panels, etc. --Jeisenbe (talk) 17:39, 17 October 2020 (UTC)
As electricity=generator has only been used 64 times and would still be correct (we might lose information as to the origin of electricity of the generator but the tag would still be appropriate), I'd be inclined to keep it as defined in the proposal. Especially as the wiki-page mentions "powered by a portable generator, usually petrol or diesel" - this doesn't mention the origin concretely, so I think the meaning is the same as before. Specifically, I think electricity=offgrid could be confusing as the direct link to power=generator isn't made. Even solar panels are technically photovoltaic generators. - Luke (talk) 16:15, 18 October 2020 (UTC)
I think this part of the proposal needs improvement. I think the term generator is too strongly attached to a diesel generator to be used in the context of roof top solar. If you have rooftop solar you wouldn't say you have a generator. I know that the name itself is not as important as how it's documented, but fear in this case it would be easily confused. In this context here the term is used as the opposite of the grid, it's for local sources like rooftop solar, diesel generator, rooftop wind etc. So the value electricity=offgrid would be better, oh I see @Jeisenbe came to that conclusion as well. --Aharvey (talk) 23:17, 29 October 2020 (UTC)
Generator is the correct term, even for solar panels, and already used for power=generator, which is why I would prefer it. Do you think a more extensive explanation and some examples of perhaps houses with solar panels or wind turbines would be sufficient? - Luke (talk) 13:08, 30 October 2020 (UTC)
Absolutely if the intent is to have all these things covered by "generator" then I think including them as examples with pictures to make it clear that a solar panel is a generator in this context. --Aharvey (talk) 23:46, 30 October 2020 (UTC)
I think it's good now that the description makes it clear generator isn't only a diesel generator, but roof top solar etc. as well. And you're right this fits in well with the existing power=generator. --Aharvey (talk) 02:30, 3 November 2020 (UTC)
I was thinking more about this on the way home just now, and your example from below came to mind: Tagging places with a grid connection but backup generator available as either electricity=grid;offgrid or with electricity=grid and electricity:backup=offgrid seems nonsensical. - Luke (talk) 14:00, 30 October 2020 (UTC)
I like the current example where a hospital has electricity=grid and then backup power with electricity:backup=generator. --Aharvey (talk) 02:30, 3 November 2020 (UTC)

At camp sites

Currently, the tag power_supply is recommended at the camp_site pages, however this tag seems ill-suited as it has evolved to describe individual sockets. I think the electricity tag would be a more apt descriptor and the wiki pages there should possibly be revised if this proposal is accepted. I've also had things that I had tagged as electricity changed to power_supply, so the scope of each tag should be discussed. - Luke (talk) 11:09, 17 October 2020 (UTC)

multiple values

Resolved: separate namespaces now allow modular tagging of multiple values Luke (talk) 16:28, 29 November 2020 (UTC)

How about places with a grid connection but backup generator available, or with grid connection + rooftop solar. --Aharvey (talk) 23:09, 29 October 2020 (UTC)

I would have no problem tagging that with electricity=grid;generator. Perhaps an extension like electricity:backup would be useful for hospitals as well and would also be a useful tag? - Luke (talk) 13:08, 30 October 2020 (UTC)
I'd like to see an example on the proposal page because it's quite common to have both rooftop solar and a grid connection, neither is really a backup, rather when it's sunny the solar is used and either excess is fed back into the grid or the grid supplements the solar to power the home, so in this case I wouldn't use the backup key but two tags at the same level. electricity=grid;generator is one solution, though I believe the semi-column separator is controversial, the alternative approach in other tags would be to namespace like electricity:grid=yes + electricity:generator=yes. Although I don't have any strong opposition to the semi-column, I'd probably prefer the latter as it's a bit cleaner. Then the question is if you keep both electricity:grid=yes and electricity=grid as synonymous or you change the schema to force only electricity:grid=yes format to avoid two different tags for the same thing. --Aharvey (talk) 02:36, 3 November 2020 (UTC)
The entire reason why I wanted to make the examples with tagging was exactly that scenario - I'll go add it. I also used electricity:generator:origin=* for the hospital example and agree that electricity:generator=yes is cleaner. I dont like semicolons too much either. I think I'd then be in favor of solely having electricity:generator=yes/no. - Luke (talk) 20:48, 3 November 2020 (UTC)
+1. I've also added this to the main tagging section then. --Aharvey (talk) 21:08, 3 November 2020 (UTC)

separate out electricity source from power supply avaliable

I feel this proposal mixes two different concepts, one is the electricity source, so does this house have electricity running to it, the other is does this feature provide electricity supply to customers, eg. so I can charge my caravan, my car, my phone. They are two separate concepts and should be more clearly distinguish like with electricity_source=* and electricity_supply=*. --Aharvey (talk) 23:23, 29 October 2020 (UTC)

Yes, it does - I originally came to the proposal from the camp_site/amenity side of things, while it was originally planned for remote areas. During humanitarian crises, I could well imagine that it would be useful to group the two together however. I was thinking that this could be mainly regulated by the access tag, with the assumption being that access=no/private in case it's not tagged, and then being explicitly tagged with either access=yes or customers in case it is available to the public. - Luke (talk) 13:08, 30 October 2020 (UTC)
I guess so then. Must be the namespaced access to distinguish the access to electricity over access to the amenity, but I can see it's already documented as the namespaced variant electricity:access=*. --Aharvey (talk) 02:40, 3 November 2020 (UTC)

Payment and Access

Without looking at the wiki (few people do) I'd parse electricity:fee=customers as meaning only customers have to pay a fee. And then wonder why customers have to pay but non-customers do not. And then wonder if "customers" meant customers of the facility or customers of the electricity. And then look at the wiki. I assume you intended to mean that customers of the facility do not have to pay a fee but the general public do. Maybe this should be handled as a conditional.

The electricity:access=* values don't play well with electricity:fee=*. You have electricity:fee=yes stating that it is accessible to the public (rather than just customers) but also there is no fee (which there could be, if "customers" is interpreted to mean customers of the facility rather than customers of the electricity). You have electricity:fee=customers stating that access is for both customers of the facility and for members of the public who pay a fee. My interpretation of "customers" does not include non-customers who pay a fee. This is not only confusing, it mixes access and fee together. --Brian de Ford (talk) 13:34, 30 October 2020 (UTC)

I agree that the access definitions can be confusing, I took the definition for access=customers direactly from the access wiki-page. I can't find where I saw fee=customers, I noticed it was missing from the fee page. So, perhaps simply leaving it at fee=yes/no would be most understandable? Also, I didn't understand your second sentence, did you mean electricity:fee=no? - Luke (talk) 13:57, 30 October 2020 (UTC)

Sub-keys of electricity

I would suggest that the subkeys below the main 4 electricity=* keys should be dealt with in separate proposals. The four main keys are clear and straightforward, and present a nice, neat case, while the sub-keys go into a ton of detail that isn't fully thought through. By having such a large number of tags to vote on at once, you'll aggregate no votes from people that disagree with any one part of the proposal. If this proposal and vote were limited to just the four main keys as a first go, I think it's a strong proposal. ZeLonewolf (talk) 23:50, 30 October 2020 (UTC)

I fear that you are probably right, but I'm not quite sure how to reign it back in since most of the discussion is about the origin tag, which really isn't even as important as having a well-developed tag for electricity in general. If no consensus forms, I would probably try to limit to just the electricity tag for now until further bugs are ironed out. The discussion page is very chaotic now unfortunately. - Luke (talk) 00:33, 3 November 2020 (UTC)
I see no problem to make all keys reviewd during the same vote but it may be great to improve the proposal chapter with list of what wil be approved at the end of the vote. See how it's going on Proposed_features/Pumping_proposal Fanfouer (talk) 22:05, 5 November 2020 (UTC)
Thank you for the link - I'll rewrite the proposal here to make it a bit clearer. I also like the way they differentiate between mandatory and recommended tags, which would be necessary here too. Perhaps the best way forward is to limit the vote to the redefinition of the main electricity=* tag and the deprecation of power_supply? And then have another vote on electricity:origin, which is likely the only really contentious sub-key. Does that sound reasonable? - Luke (talk) 15:55, 11 November 2020 (UTC)

origin of different sources

This feds on from some of the other comments I've raised, but where you have for example a house which has both rooftop solar and a grid connection, you'd either have electricity=grid;generator or electricity:grid=yes + electricity:generator=yes depending on the outcome of that discussion.

However with only a single electricity:origin=* tag you can't specify which source grid or generator this relates to or specify a different value for each. While I suspect that most national or regional grids would be comprised of a range of origins and hence won't be tagged we should still ensure the tagging is unambiguous in this scenario.

I propose as a solution to namespace again like electricity:generator:origin=solar where there are multiple electricity sources. Where there is a single electricity source then it doesn't need to be namespaced and electricty:origin=solar would be fine.

Really appreciate your effort on this proposal, I think it's shaping up well. --Aharvey (talk) 02:48, 3 November 2020 (UTC)

To me it's not obvious we need to mention origin of electricity coming from a local generator as you are able to make the link and find the proper generator:type=* value on the power=generator feature. What if you have several generators with different inputs each?
One possible solution would be to use electricity:origin=* with electricity:grid=yes only. Fanfouer (talk) 21:56, 5 November 2020 (UTC)
I don't see the harm in copying the tag over, especially as this would make searching via overpass etc. much easier to implement. Otherwise people would need to tag a relation that links the generator with the end user. In the case of multiple types of generators I would most likely say that semicolon tagging is the easiest there although unfortunately not well-supported by apps and the like. - Luke (talk) 15:59, 11 November 2020 (UTC)

top level electricity tag where subkey variants :grid, :generator, etc are used

The example of a house with both grid and rooftop solar was changed in https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/electricity&diff=next&oldid=2056478 by @User:Gausserrorfunction. We need to discuss this, I assumed since both sources are equal with no one being more major than the other that you would not have a top level generator key and instead only use the subkeys. So I think we should revert this change and possibly add a note to not add the top level tag in this case. Any opinions? --Aharvey (talk) 12:01, 5 November 2020 (UTC)

Thanks for mentioning this, I wasn't notified about the edit by him. The change should be reverted. I had tagged the new example using the tagging scheme we discussed, but was hoping to hear some feedback from the rest of the community before completely switching the wiki page and all examples to the newer scheme. I'll think I'll do that now then and send a new email to the list. - Luke (talk) 13:10, 5 November 2020 (UTC)

Required top-level tagging

First off - thanks for all the hard work here, this is really shaping up nicely.

Regarding the statement:

From a data consumer perspective, making electricity=yes optional makes data access harder because now a data consumer must search multiple keys to determine whether or not something has electricity. I would offer instead as a possible alternative:

This would work great with your current :fee, :origin, and :access schemes to further spell out details about the electricity, and allows for data consumers to query a single key when determining whether or not there is electricity available. It also simplifies your table and explanations while still conveying the same information! ZeLonewolf (talk) 17:21, 5 November 2020 (UTC)

Thank you for proposing this as I was wondering the same. However you'll find buildings that are fed by the grid AND a generator as well to prevent any outage when grid won't be available. That's why we need both electriciy:grid=* and electriciy:generator=* Fanfouer (talk) 21:59, 5 November 2020 (UTC)
That's a great point. I would then offer a fifth value:
  • electricity=backup - electricity is available from the grid, but backed up by local generation when the grid is offline.
That covers all cases, no? I do think it's important that whatever scheme is settled on that there always be a electricity=* key that can be reliably used by data consumers. --ZeLonewolf (talk) 22:17, 5 November 2020 (UTC)
That's a nice one which brings us really near of a complete solution but we miss the most and most common domestic situation when local generator runs on-grid like PV solar panels. Auto consumption currently raises in developed countries and it's no backup but a complementary operation. We should find electricity=backup for gasoline engines waiting for an outage to occur and electricity=complementary_supply (or nicer equivalent) for houses connected to grids with panels on the roof Fanfouer (talk) 22:58, 5 November 2020 (UTC)
I have seen articles about grid electricity as a backup source in the future and would also consider that something like electricity:battery=yes might become relevant soon as Tesla Powerwalls and the like are built. But perhaps just take out that sentence and change it to the way Harvey originally proposed: electricity=yes should be used when electricity is available and the lack of knowledge about the infrastructure is signified by the lack of electriciy:generator=* and electriciy:grid=* tags. That makes more sense overall anyway now that I think about it and would probably lead to less tagging error. Also, I think distinguishing with electricity=complementary_supply and electricity=backup is not a very elegant solution as each potential combination has to be spelled out - Luke (talk) 23:05, 5 November 2020 (UTC)
Batteries could indeed be a backup solution (just like generator). I find more interesting to tag a backup instead of the mean used to provide it (generator, batteries). Most of the time you know there is a backup but you don't know what is used behind the socket.
We could find more elegant values (backup_generator, complementary_generator for instance) to deal with backup and auto consumption but do these only two situations require two namespaced keys? Do you have any other possible situation in mind that could lead us in favor of namespaced tagging? (because 3 combinable situations is way harder to translate in a single key) Fanfouer (talk) 23:15, 5 November 2020 (UTC)
Perhaps electricity:backup=* which uses identical values to electricity=*? That allows electricity:backup=yes, electricity:backup=generator, etc. as needed. ZeLonewolf (talk) 23:20, 5 November 2020 (UTC)
Something like having a battery wall as a day-to-day storage and a PV system as generator could become commonplace with a grid connection being the backup in case one of the former fails, especially in industrial settings. I'd try to keep things as modular as possible since I expect that the infrastructure available will change rapidly within the coming years. Is there a disadvantage to namespace tagging? The electricity:backup=* was my original idea but then leads to electricity=grid;generator being necessary for houses with an always-on PV array that have feed-in tariffs. From what I've seen semicolon lists are not handled well at all by either overpass or any of apps. - Luke (talk) 23:24, 5 November 2020 (UTC)
That's right and I think semicolon tagging is worse than namespaced tagging. It's simpler to have a single key with independent values instead of namespaces (but I'm happy with namespaces too, no problem).
As it's true an always on generator could be used as grid backup doesn't invalidate the independence of values as follow:
  • electricity=no - electricity is not available
  • electricity=yes - electricity is available, without further specifying where it comes from
  • electricity=grid - electricity is available & connected to the grid only with no backup and no always-on generator
  • electricity=backup - electricity is available from the grid XOR a backup supply (battery or generator, whatever)
  • electricity=complementary - electricity is available from the grid OR an always on local supply (battery or generator, whatever)
  • electricity=generator - electricity is available from a local generator only with no grid
No supplementary value sounds to be necessary, don't you? Fanfouer (talk) 23:40, 5 November 2020 (UTC)
Complementary is not quite right, perhaps something like "redundant", as in "redundant power". --ZeLonewolf (talk) 23:47, 5 November 2020 (UTC)
I agree that semi-colon separation is terrible! I think namespaces are fine, and Any_tags_you_like permits their use explicitly when the thing being tagged is complex. And, this topic does appear to be complex. In the specific example you give (something on solar panels with grid backup), perhaps something as simple as electricity=solar + electricity:backup=grid? In any case, I think you guys are on the right track here however it settles. --ZeLonewolf (talk) 23:43, 5 November 2020 (UTC)
I'd be very against using a tag such as electricity=solar as this then conflates the electricity tag with the electricity:origin tag. The electricity=complementary tag also loses information about what type of local supply is available. If you've taken a look at the current tagging suggestion, using the electricity=yes and electricity=no tags as parents seems easiest and then any additional info can be tagged using the suggested subkeys (of which there are now many...). But it is a complex topic and I'm definitely not able to predict the future of technological innovations to come. - Luke (talk) 23:53, 5 November 2020 (UTC)
That's fair. I guess the question that needs to be answered is whether all locally-generated electricity is covered by electricity=generator, including both fueled generators and renewables such as wind, solar, etc. ZeLonewolf (talk) 00:02, 6 November 2020 (UTC)
I think it's ok to group the locally-generated electricity together since the distinction can be made using the origin subkey. It could get a bit murky in the case of very small local grids to distinguish between grid and generator, but I don't know how prevalent that is in the world. - Luke (talk) 15:44, 11 November 2020 (UTC)

Electricity=no + sub-keys

Is there ever a situation where electricity=no would be used with sub-keys? --ZeLonewolf (talk) 00:06, 6 November 2020 (UTC)

Perhaps if there is a long-term power outage it might make sense to change electricity=yes to electricity=no while keeping the subkeys. Apart from that, I don't think it would ever be used together with the subkeys. - Luke (talk) 15:40, 11 November 2020 (UTC)
If there is a temporary disruption of the normal state, then the 'temporary:' syntax should be used without changing the normal tags at all. --Mueschel (talk) 19:11, 14 November 2020 (UTC)

electricity:schedule vs. electricity:conditional

Resolved: Fixed tagging to use conditional syntax properly Luke (talk) 16:30, 29 November 2020 (UTC)

A 'schedule' prefix is not yet used on any other tag. Every other tag I encountered either uses a time (as in opening_hours syntax) directly as value or relies on the well-defined ":conditional" syntax. I don't see a reason not to use the common 'conditional' scheme here. --Mueschel (talk) 19:09, 14 November 2020 (UTC)

Ah that was still a remnant from the old proposal as I have no experience with conditional tagging. Do you mean to then have something like electricity:conditional=yes @ (Mo-Fr 8-10)? Looking at the wiki page for conditional tagging, that seems to be the standard syntax - thanks for bringing it up! I'm not quite sure how to tag intermittent electricity then when it is irregular. Perhaps as electricity=intermittent? Although it would be nice to have a similar syntax to regularly scheduled fall-outs. Perhaps electricity=yes @ irregular or something like that? - Luke (talk) 19:44, 14 November 2020 (UTC)
It is still unclear when we should use electricity=intermittent. When I lived in Sentani, in Indonesia, the power would go out for a couple hours, every other day, at random times, but it was available for at least 20 hours a day. Is that electricity=intermittent or electricity=yes? What if there is only electricity for 3 hours every evening on a regular schedule? Is that electricity=intermittent or electricity=no or electricity=yes? It seems like this proposal is only designed for mapping developed countries and has not considered other situations. --Jeisenbe (talk) 07:27, 1 January 2021 (UTC)

Is electricity:origin=* still proposed?

Resolved: electricity:origin is not part of the proposal anymore Fanfouer (talk) 16:14, 29 November 2020 (UTC)

Hi, following recent updates of the proposal, electricity:grid:origin=* and electricity:generator:input=* seem now enough to specify both grid origin and local input. Will this proposal make electricity:origin=* approved and why is it still necessary? Fanfouer (talk) 14:52, 29 November 2020 (UTC)

It is not a part of the proposal anymore and I just removed some mentions that I had overlooked yesterday. - Luke (talk) 15:52, 29 November 2020 (UTC)

Batteries

I currently wonder if batteries can be considered as a proper source or as a mean to backup/improve quality of electricity, even punctually. Let's say, when batteries are installed in a building, electricity actually comes from a grid or a local generator or both. As to properly invert sources in case of outage, an UPS may be available. This UPS is not only responsible to provide alternative voltage out of DC from batteries but normalise power grid wave frequency and voltage (as to prevent any damage from poor quality power grid).
How do you feel with electricity:grid=ups which means that power grid wave is filtered by the UPS and will also use batteries as a backup if required?
electricity:generator=ups would be applicable when a local generator is the main power source with batteries as backup.
That should be verified but I think an UPS is always found when batteries are used as backup and I'm not aware of UPS setups without batteries
Additionally, electricity:battery:type=* shouldn't be mentioned if it is not approved by this proposal review Fanfouer (talk) 15:14, 29 November 2020 (UTC)

In some cases, batteries are used as a proper source, i.e. used daily - especially in off-grid environments (see last example for instance). I would leave the tags for :grid, :generator and :battery to solely mean if they are connected or not and if they are used daily or not, i.e. yes/backup/no and move further tagging as to the type of connection (exact configuration of a UPS system) to different tags as the types of systems are likely to change in the future. I think the mandatory tags should be fixed and cover all general scenarios so that the tag is still useful in 50 years. Specifics should then be covered in subkeys. Perhaps you have a good idea on how to implement this? Also, I've clarified that the battery:type is not part of the proposal. - Luke (talk) 16:03, 29 November 2020 (UTC)
As I understand you, when a building is provided with batteries and local solar-generator off-grid, you don't consider batteries as a backup?
electricity:grid=ups could be reviewed in a further proposal, no problem Fanfouer (talk) 16:21, 29 November 2020 (UTC)
Yes, I would consider backup something that is not typically in use, so perhaps every week or once a year. Something like a battery bank that's used every night wouldn't be backup in that case. - Luke (talk) 17:49, 29 November 2020 (UTC)

Sources vs supplies

Resolved: Source is the good wording here Fanfouer (talk) 17:52, 29 November 2020 (UTC)

As it was discussed previously about source vs origin, it's now a detail but the proposal should deal about power supplies instead of power sources as to not collide with OSM's source sense. This could allow to completely remove source wording Fanfouer (talk) 16:24, 29 November 2020 (UTC)

I don't see a problem with the word source here as it is not used as a tag and the meaning should be clear. Power supplies are specific electrical devices and is definitely not the right word here: power source vs power supply. - Luke (talk) 16:38, 29 November 2020 (UTC)
Indeed, that was wrong memories from past discussions Fanfouer (talk) 17:52, 29 November 2020 (UTC)

Business Details

I'm on record as saying that we are not a business directory. While we do sometimes map certain features of a business - like opening hours, contact details, or whether the premises are wheelchair accessible -, we should refrain from mapping things that are simple contract or advertising issues. These things can be changed willy-nilly from one day to the next and they are pure marketing decisions. We are not a database of supermarket marketing decisions. OpenStreetMap is not a tool to find the best vendor for a certain product, and we should not attempt to be that. Just because some people might want to base their purchase choices on whether a supermarket buys green energy, that doesn't mean we should record that. Other people might want to base their purchase choices on what prices the supermarket offers (we don't record that), or on the gender identity of the shop owner (we don't record that) or on whether the business donates to a particular political campaign (we don't record that). So why would we record where the supermarket buys their energy - that's a check box in a contract form and it can be clicked off next month. We can't keep that information current so don't add it. It will mislead more buyers than will profit from it. --Woodpeck (talk) 17:34, 1 December 2020 (UTC)

Sensible Defaults

This proposal needs clear wording that discourages its usage in situations where it is the default. In an urban western setting I don't want or need the information that every house is connected to the grid (and if one house chooses not to be connected, maybe that's a personal decision of the owner and not our business either). --Woodpeck (talk) 17:34, 1 December 2020 (UTC)

This was discussed on the tagging list as well: even though tags such as building:height, building:material, natural=tree exist, this doesn't mean they need to be implemented whenever possible. The same is true in this case. I can add a further sentence stating that the tag should only be used when it is deemed significant, but I'm loathe (and not allowed?) to change the proposal as worded during voting (and assumed that this is given in the way it is for every tag in OSM), but can add it afterwards. However, a tagging scheme that allows for the tagging of electricity would be beneficial.
Also, I came from the standpoint of wanting to tag features in the western world - for travellers off the beaten track this is valuable and missing information. It's not feature creep at all. - Luke (talk) 18:30, 1 December 2020 (UTC)

Never change the existing meaning

Changing the meaning of already established tag values is a bad idea, as it would destroy the meaning of both the old and new values irrevocably!

  • Firstly, it not explicitly stated what new meaning of electricity=yes exactly means. Does it imply customer can have access to it to charge phone? Does it imply existing heat or lightning (as proponent implies in some comments)?
  • Secondly, in comments, there are conflicting definitions: one claiming that for new electricity=yes "The implied value is private" and in the other comment that new proposal is "consistent with old" (and old definition and usage did not imply private).

If the new electricity=yes does not mean exactly what it meant before (which is "There is electricity but the source is unspecified.") then it will create a collision which would not only make the new tag electricity=yes useless, but would also destroy meaning in all old values, as it would be impossible to know which one is meant.

And "was used only 500 times" when tag meaning changes is not trivial at all as proponent implies: as it means at minimum that you need to resurvey 500 places around the globe, and also contact and convince all the mappers that used old syntax to stop doing what they were doing and do it the new way, and update all documents and recorded video presentations etc. on the web and elsewhere, in which electricity=yes means something different now - it is realistically impossible.

So at the very least, to avoid horrible breakage, values that have (even slightly) different meaning they did before need either:

--mnalis (talk) 16:38, 25 January 2021 (UTC)

According to Proposed_features/electricity#Tag_transition, electricity=yes remains unchanged in meaning. It just indicates that the entity in question is supplied with electricity. To whom this electricity is available is left undefined. --Gausserrorfunction (talk) 13:08, 26 January 2021 (UTC)
that would be good, if the proponent "Luke" himself didn't state himself on "17:33, 22 January 2021 (UTC)" that "The implied value is private" in comment clarifying what electricity=yes exactly means (search the page for that exact phrase, in voting section). So we have a conflict by the proponent himself in what is exactly meant by that tag. Usually the last statement/clarification is what matters (as older one might be result of unedited copy/paste from previous version). At very lest, there is an serious error that needs fixing/editing with extra clarification. Or the meaning is not what is written in other section, which again needs fixing with extra clarification what is intended. --mnalis (talk) 19:09, 26 January 2021 (UTC)

proposal problems / clarification requests

(Italicized are Luke's (the proponent) clarifications, and rest is my questions / assertions.)

  • "I never mentioned that electricity=yes/no has any connection in OSM to the tags for lighting or heat!" -- then what did you mean by "Consider a campground with private electricity (i.e. lights, heating etc.)" sentence above? It implies to me that you meant to indicate some connection there? Or if there is no connection, what does that sentence mean and why it mentions heat and light at all?
  • "Rather, there is a real world difference between electricity:access=no and electricity=no" -- can you elaborate what you perceive as a real world difference between "no access to electricity" and "no electricity", and how that difference is useful for this proposal rationale (travelers and tourists access) and how it impacts OSM tagging? Especially given that electricity:access=no is not the same as electricity:access=private ?
a waiting room have electricity (lit, vending machine) without any plug, private is wrong since it would mean you can assk the staff on case-by-case basis electricity=yes electricity:access=no} --Marc marc (talk) 08:21, 1 February 2021 (UTC)
Existence of working vending machine should be marked with amenity=vending_machine (weather it is operated by electricity, by coins, or manually by operator with key, is mostly irrelevant for the user, who might instead be interested if it accepts cash or credit card). Same thing with light - its existence should be marked with lit=yes. Light does not imply electricity (it could be gas light, or petroleum ones popular in 3rd world countries), nor does electricity implies that there will be light (in many places it's not). Same with heating / cooling etc - electricity does not imply them, nor do they imply electricity (especially outside of 1st world countries, and then mostly in cities and not slums for example). So do not confuse electricity with other forms on energy or work that it might be converted to if additional hardware is present, working, end enabled (which is quite a stretch to assume!). electricity=* should be marked only if electricity ITSELF is available (and if it is available, the most important question immediately becomes "available to whom?" and via which socket? -- because, it it's not available to YOU, or YOU cannot access it due to incompatibilities, it might as well not be there as far as YOU're concerned) --mnalis (talk) 16:58, 1 February 2021 (UTC)
  • "and so the two shouldn't be conflated as mappers may think something is mistagged" -- I don't say that they should be conflated, I'm saying that electricity=* is buggy and superfluous and should be removed/obsoleted completely. I don't see why you think mappers would think something is mistagged if it is using common practices, does not conflict with old tags with same name, and is neatly defined in wiki? If anything, redefining old tags to mean new things like electricity=yes) would be highly confusing to mappers (and not only them!)
if you delete one of the 2 tags, then you need 2 extra values :
no : no electricity
yes : electricity (generic value)
yes-but-no : electricity but a request on a case-by-case basis is not possible
private: electricity but not accessible to the public (request on a case-by-case basis always possible)
customers : electricity available to the public
everyone: electricity accessible to anyone, even without being a customer of the establishment
mixing 2 infos in one key is not nice Marc marc (talk) 08:21, 1 February 2021 (UTC)
Marc, you should take a look at defined values for access=* -- most notably "yes" means what you mean by "everyone", and "unknown" seems to mean what you use "yes" for; your "yes-but-no" would be either "permit" or "no", depending on the case, etc. Please do not change the standard "access" (sub-)tag meanings, that would create chaos! My point was that difference between "having no electricity", and "electricity being brought to building but nobody having access to it" is moot in my opinion. But if you think that distinction is important in some case, you can always mark it is electricity:access=unknown and describe it in detail in description=* - there is no way all possible details ever could be described without it! --mnalis (talk) 16:58, 1 February 2021 (UTC)
  • "If you would take a look at the amenities tagged with electricity=yes, you would see that most would likely be electricity:access=private" -- I did: https://overpass-turbo.eu/s/12P5 and I absolutely do not see it like you do that they should be marked as electricity:access=private". More likely it looks the majority I looked at would be electricity:access=customers", but that is also just wild guessing, and wild guessing is absolutely not something that should be mapped in OSM. Instead it should be resurveyed, or left as-is with old meaning of tag (which means do not reuse electricity=yes to imply values it did not imply before!)
  • "I definitely wouldn't automatically tag these with an access tag, but I think it is reasonable to say that electricity has an implicit access value and that we then rather err on the side of caution." -- I'm not opposed to implied meaning of the new key/value pair; but I am absolutely opposed to redefining what existing key/value pair means (as it breaks the meaning for all existing meanings, as well as all new meanings). If you were to say for example electricity=have implies amenity having private access to electricity and electricity=yes is deprecated old value, I would not have complaints on that proposal (at least not on that grounds - I would still think it is a bad idea as it would be confusing and error prone for new users which would likely assume different meaning unless they visit the wiki)
  • "As the electricity=yes tag has been used previously, I need to somehow define it in the context of this proposal" -- I agree: but you should define it as "deprecated"/"do not use" with exact old meaning. In fact, you should define whole of electricity=* as "deprecated" / "do not use", for reasons outlined in my original vote and comments.
  • "Alternatively, one could define electricity=yes as only public-access as suggested above, but this would then definitely conflict with the old proposal.Thus, this seems a reasonable compromise." -- I agree that implied public access is also bad idea, as it conflicts with old value. But so does implied private access, which also conflicts with old value. So only reasonable thing is to not use that "yes" value at all and mark it is deprecated.
yes is a common rule which includes all the more specific value (exept no of course). it makes no sense to depreciate yes Marc marc (talk) 08:21, 1 February 2021 (UTC)
I agree that yes often (but not always) have well defined meaning. It has clearly defined value at electricity=yes - I'm only against using to mean something different than what it already means on all currently existing elements (which proponent proposes - implied access rules etc.) There is no problem (in my opinion) if proponent proposes to keep it to mean exactly the same thing that it did before (which is, I'm quoting: "There is electricity but the source is unspecified").But the original tag definition was more like "electricity:origin" than new proposal, and if that semantic is something that we want to keep, it is fine, but needs more work on modifying proposal. But previous meanings cannot easily be changed (not without all the problems mentioned above, resurveying all the current places before activating a new meanings being only one of them). --mnalis (talk) 16:58, 1 February 2021 (UTC)
  • "The number of mappers that have used the electricity=yes key is sufficiently finite" -- sure, everything is finite, but which percentage of them did you manage to reach and confirm their position on the subject? There is difference between "finite" and "easy".
  • " and one could also include in JOSM at least a validation check" -- there are more editors than JOSM, and somebody would need to write the checks, and users need to get new versions. It takes time and effort, and is never 100% successful. For example, Debian JOSM users would likely get the new version several years after the fact - should we put several years moratorium on use of new values? I think not. It is waaay much easier to define new keys/values smartly in non-conflicting way, even if it means one more proposal update and one more round of voting.
  • "a parent tag for the various subtags is far from useless as it helps with filtering and quality control of the sub-tagging." -- this I strongly disagree with. Writing overpass query that for example filters out both "electricity=no" and "electricity:access=no" is at least double the work than having it check just the later. Same for all other combinations. And then there is possibility for problematic/nonsensical combinations (as I mentioned before) that makes handling two tags much more complex than handling one, and introduce uncertainty and unreproducibility (eg. one app says there is electricity for you, and another app saying there isn't, on the same dataset and using same set of rules, just by different ordering of queries). Having multiple tag in this way breaks normal form https://en.wikipedia.org/wiki/Database_normalization on purpose, and is is a nightmare for programmer and data consumer.
  • "...quality control of the sub-tagging" -- what is this supposed to even mean? Hopefully not what it looks like to me - "that the subtags might be wrongly mapped, so we add another tag with same meaning so we can have conflict if both tags do not say the same?". If it is supposed to mean that, than it is a terrible idea. We do not propose "highway_type=vehicle_road" to have quality control is someone has mistyped "highway=primary" as "highway=footway"! People should enter correct data, and if they enter wrong data, someone should correct it. It is as simple as that, none of this "multiple tags as checksum substitute"!

I'd appreciate your further views on each of those points, Luke! I've bolded most important parts for each of my questions for easier navigation --mnalis (talk)

split to improve and make it more readable

the proposal is not perfect, but it has the merit of working on a real problem because there are 2x2 tags (power_supply -> socket and power_supply=yes/no -> electricity) with the same meaning, in addition to possible missing tags.
to improve the quality and success rate of the next round, consider spliting :
- power_supply -> socket when the value indicates a type of socket
- =none -> =no: in my opinion it doesn't need a proposal, =no is the right value according to osm habits, for existing values, so talk on tagging ml, fix the wiki and then run a mass editing procedure
- electricity:origin
- electricity:grid=* electricity:generator=*
- electricity=* tag itself
advice : when a proposal is *not* about storage, don't talk about it at all or just say it will be for another proposal without any key be as simple and as small as possible to avoid the "too big to success" issue :) --Marc marc (talk) 22:52, 31 January 2021 (UTC)

Marc, would you also include electricity:access=* -- that is (for me) absolutely the most important part of the proposal? If I can't benefit from it because I don't have access to the said electricity, it's existence is much less relevant to me and other travelers this proposal aims to cater to (according to its rationale). --mnalis (talk) 16:58, 1 February 2021 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Electricity&oldid=2513633"