It proposes new tagging to ease mapping for individual connections to power grids or telecommunications wires:
A new value line_management=service_supply
A new key occupancy to state how much connections are visible without mapping them.
Examples and situational sketch give all necessary details about this.
As the 15-days period would end this vote right before the SOTM, I plan to close it right after on Sunday 30th August at 20:00 CEST. I will attend the conference in Paris and will be available for chat or clarification about it there.
You are kindly invited to give your opinion at the bottom of the page.
It isn’t going unnoticed that a new tactic is being employed to get controversial proposals over the finishing line. Wait a year or two and then spring a surprise vote on the community.
As the voting rules are clearly designed to cater for the case when RfC and voting are close together, the terms are far to short for something for which you have to go back and review the relevant discussion.
extending line management tag to all services including water seems dubious and from proposal text was supposed after other proposal doing this properly
First of all for power and more broadly for telecommunications, water, gas… (waiting for a formal proposal for line_management=* to support pipelines).
Why not make the voting wait until after SoTM for any further questions and explanations?
Are there any precedence on multilingual proposals? Allowing voting on 2 pages seem disorganized and fragmented. The section should be centralized. Proposal:FR:Service supplies proposal - OpenStreetMap Wiki
We need to elaborate on the controversial sense here. RFC gave a reasonable amount of comments which has been processed. Where is the controversy according to you?
What you perceive as a tactic is actually an obvious lack of time for processing (for whatever reasons). I’m sorry.
That’s brand new actually and the first time I read it as an actual problem.
The proposal process gives at least 2 weeks between RFC announcement and voting, nothing more. Can you provide additional rules I may have missed please?
If there is anything I can do to save time and clarify without needing to process all the preceedings, please ask but blaming me for something I’m not guilty of is not a good start.
Yes it is waiting. The RFC was helpful to figure this out and it was resolved on the talk page
The I case of the situation sketch confirm it’s currently unsupported for pipelines.
Then you oppose something and I agree with, it won’t happen at the end of this vote.
There were no new questions on this proposal for 6 months. The vote may have started earlier if I had time to process faster (nothing related to a particular strategy).
No one is forced to participate to RFC. Voting phase also favors point making and actual progress as proponent will get feedback it could process for a sometimes necessary revision.
I actually thought about SOTM and the voting ends after it, so discussions are still possible, always.
French page redirects votes on the English one. I already translated several of my proposals and obviously only the English versions were open to vote.
I remember some translated in several language as well, without problems.
“This proposal is intended to cover any utility network” this does not exclude water pipes and would further extend Key:line_management - OpenStreetMap Wiki that is (at least for me) extremely confusing already
Like other power- related mapping like that circuit relations, tap points and other.
There is a difference between the design, i.e. we develop some tagging with a broader set of knowledge or constraints in mind and what gets actually voted.
Service supplies refer to almost any utility connection between consumers and utility infrastructures. I took care of this fact when proposing this new value, nothing more. It doesn’t change the scope of usage for line_management=* as correctly pointed out during the RFC.
I deliberately seek for a value that doesn’t involve power or telecoms in its wording to remain compatible with other utilities after any possible scope change, if necessary.
It looks like you confuse malice and constraints anyone may face when involved like us.
Will you ask every author to restart/abandon their proposals open for RFC since many years as to not be surprised if voting opens one day?
I would note that it isn’t as if this would cause you a tremendous amount work, just announce that you are restarting the proposal and reset the timers. Then when commenting time has passed, start the vote.
It extends it to nonpower uses while current documentation describes it as specifically for power and telecoms and mentions extending it for other utilities as possible future change
I am confused by this claim given that Key:line_management - OpenStreetMap Wiki describes it as for power and telecoms and that proposal has “This proposal is intended to cover any utility network”
I’ve got it and I fail to make it clearer despite my attempt upside.
Both claims “this proposal is intended for all utilities” (i.e I’ve designed the proposed value for everything) and “line_management is currently dedicated to power and telecommunications and one or more proposals will be mandatory to extend it to other utilities” are complementary and necessary for context.
Since it’s clearly stated in the proposal that nothing changes regarding line_management scope, there is no risk for anyone to sneaky move things without prior discussion. Not to mention this will clearly stated in the documentation to be added if this proposal get approved and our discussion is linked to the current vote.
this conflicts with “Utility networks like electricity, water or even gas often go along streets” mentioned in the very first sentence and “This proposal is intended to cover any utility network.”
I predict that this proposal will be used directly to redefine line_management scope or as justification to do this.
These electricity-related taggings are already extremely confusing, without trying to model sewer networks at the same time.
Actually, using line_management for pipelines is not trivial, despite what I thought prior the RFC.
We need to look and define how this could become possible, I’m less convinced of this currently and further thinking will be needed. What we will found may discourage us to so, I currently don’t know.
Discussing this document had the advantage to show this difficulty more clearly, not the opposite.
It will be reverted as possible mistake and sent to one of the existing thread about mapping pipelines. I would take this as an opportunity to understand the actual need and find a more suitable solution (because line_management is not really the core problem for this).