Power substation rendering #230
Comments
|
taginfo stats: Looks pretty clear what the accepted tag is. |
|
As you can see here : http://wiki.openstreetmap.org/wiki/Tag:power%3Dsub_station, sub_station is now a deprecated value for power=*. All features with this value will be moved to power=substation. Thus, the new power=substation has to be rendered like the old one, power=sub_station. |
A vote on the wiki page does not mean that mappers can or cannot use a particular tag or that renderers should or should not render it.
Not on the basis of the wiki page vote. A mechanical edit requires consultation beyond just the wiki or the tagging@ list. |
|
This proposal has been discussed on tagging@ and talk@ mailing list for months. It's pretty hard work to bring consistency and good spelling in tag values, massive re-tag is not what it's planned. New value should be rendered the same as the old, especially not to bring more mess than benefits on the main osm webpage. Thank in advance to take all aspects in account. |
|
2013/10/15 fanfouer notifications@github.com
yes, I agree, otherwise you would make the substations disappear (a feature cheers, |
|
@pnorman: Just because we have this new tag, power=substation doesn't mean that we're going to get rid of the rendering for the old tag power=sub_station. We'll keep the old one for backwards compatibility and add the new one to keep up with the latest times. |
|
Then why bother changing the tag? Should we next have a vote on whether it should be spelt railway or spelled railroad? The problem here is not that the tag is mis-spelled, but instead that people are worrying about tag spelling when we should be encouraging people to edit. If enough people spell a tag using a standard incorrect spelling, or a (English standard correct) spelling, then write it up in the Wiki and people who render will know what to do. That is what seems crucial to me: ensuring that people know how to add things, and that people know what they mean once they're added. Correct spelling seems quite secondary to the matter, where correct rendering is the crux of the matter. |
|
But the new way of spelling it is documented on the wiki. The old way of Comparing it to railways is comparing apples to oranges because both words I really don't see why there's such opposition on here to adding just one On Thu, Oct 17, 2013 at 11:39 PM, Russ Nelson notifications@github.comwrote:
|
|
I should repeat what @Fanfouer said above: I don't see why this is such a controversial change. Nuff said. |
|
2013/10/18 Russ Nelson notifications@github.com
the meaning and intended usage of the tag was modified, so a new spelling cheers, |
|
While I don't have the time to keep up with Tagging@ and find the taginfo stats more important anyway, I understand the opportunistic spelling fix as a mean to distinguish old meaning from new. What I'm really sceptical about is that "substation" would be missused any less than "sub_station". That wouldn't be hard in a team of 50 contributors, but in a team of 18600... Good luck. The other thing is that the authoritative nature of a "voted and approved" proposal is often largely overestimated. You shouldn't be surprised in OSM to have to defend again and again something that has been "approved". It's a normal reaction, not an hostile one. Whether a tagging scheme wins out in the end takes time and depends on many things. All that being said, I think we can add power=substation as a synonym (as far as rendering is concerned) of power=sub_station. Maybe wait a bit to make sure that it catches up to sub_station (which currently wins 997 to 3), but that sounds likely. |
|
2013/10/18 vincentdephily notifications@github.com
taginfo is very nice to see which tags are used often and which aren't, but |
I agree, right tool for the right job. I hope I didn't convey the impression that I base my opinions solely on tagginfo ? In this case (deciding whether to render a new tag that is very similar in spelling and meaning to an existing one), I think that usage statistics are very important. |
|
You know more people will use a tag if it actually renders. Even though people are really not supposed to "tag for the renderer," they still do. So, if you render a tag, more people will actually use it. |
|
Okay, since you said you want to wait till there is more usage of the tag, that's all the more reason for me to go through and change everything over from power=sub_station to power=sub_station. I'm just going to do this manually on a case-by-case basis. I know mass retagging of deprecated features is discouraged, so don't freak out everyone. |
|
At the time of the last update to Taginfo (2013-11-02 00:59 UTC), there were 866 total uses of the tag power=substation. Meanwhile, there are 101,848 total uses of the tag power=sub_station, meaning it too has increased over the past 18 days. |
|
I would also support rendering the new value (and the old one as well for the time being). As a community, we need some kind of coordination process, and I don't see a better place for that than the tagging mailing list. @gravitystorm, I haven't seen you in this discussion yet. What would be your opinion (except that you might prefer to postpone adding new features until we are happy with the current style sheet)? |
|
@gravitystorm, I would really like to see your input. Even an 'I'm too busy to look at it right now' would be fine, as it seems that currently, people (for example on the tagging list) seem to interpret your silence as disapproval. |
|
JFYI, over 3 weeks number of power=substation uses had increased tenfold: http://taginfo.openstreetmap.org/tags/?key=power&value=substation |
|
@Fanfouer More "noise" would be extremely unwelcome. |
|
@Fanfouer I think they are doing just bug fixes right now..... |
|
@gravitystorm To be honest I can understand @Fanfouer frustration. An issue has been created, a pull request has been created, I have asked you twice for your opinion on this issue, but you haven't responded at all. I can imagine that he doesn't like that his issue doesn't get picked up without hearing the reason why. I suppose that for the contributors, more guidance from your side would help as well. I still have no idea whether you didn't respond to the issue because you disagree with the idea, because you want to focus on different issues first, or whether you simply didn't have time to look at it. Without knowing that, it's hard for me as a contributor to decide which issues/change request are worth my effort. So hopefully you will also give a more helpful response :). |
|
I thought I replied before to this but obviously I didn't. This topic was mentioned in passing a few weeks ago with GravityStorm at a London meetup. I cannot remember too much about it but I think at the time it didn't seem needed as they were very little tags (and at the time I don't think even a pull request). But also most of the work is going into refactoring/bug fixing the existing stuff rather than adding new things (there are thousands of things to add) and just getting through all the many pull requests and issues just to look over them rather than analysis and implement them is a lot of work at times. All that said I would hope GravityStorm would have replied back to explain the situation but he as never been very good at that. ;) But I am a little uneasy with the tone/expectations from others here. It makes it sound like a demand and that is no way to get things done in a volunteer community. |
|
I have invited @gravitystorm by e-mail to give his opinion on this issue. |
|
Thanks everyone for their patience, and especially to @math1985 for his gentle and unfailingly polite reminders. I waited on commenting on this for a while whilst I considered it, waited to hear from other people, and then got busy doing other things. So my first point - please always be patient. There's never any particular rush with things, and good decisions are often made carefully. I see people throwing around taginfo numbers to bolster the demands for change. They are a guide, not a yardstick. When one tagging approach is being pushed by a particular party, the numbers become meaningless. Taginfo doesn't show if mechanical edits are skewing the numbers, or if one vocal person is skewing the numbers, or if a bulk import is doing so, or if two different communities have different interpretations and are working in ignorance of one another. We've had examples of all these, in the past. So my second point is go easy on the stats. It is easy to argue that tagging needs to change as we develop OpenStreetMap, and of course it's perfectly true. But changing tags carries a large burden that I see little evidence of being truly considered by those proposing change. Where real-world features can't yet be mapped, that's a good reason for a new tag. Where existing tags are causing misinterpretation between mappers or mistranslations between communities, that's usually a cause for documentation, and occaisionally a cause for changing tags. What is less easy to justify is where we are changing one tag for another tag with identical meaning, or where there is little confusion caused by the tag or little reduction in any confusion caused by the change. Altering As an analogy this is like changing tabs for spaces in source code. Most projects have a preference - we prefer spaces in openstreetmap-carto, similarly we use underscores for spaces in tags - and consistency is nice to have especially when adding new things. Or perhaps a large software project, such as the linux kernel, has a naming convention for variables, perhaps underscores to represent spaces, but a stray underscore has crept in to one variable. While you could find-and-replace all the uses, it might not be worth the hassle. But changing tags has much larger consequences than changing whitespace, or changing a variable name. It is, more or less, our external interface to OpenStreetMap data, and have a look to see how much ABI breakage in the kernel is frowned apon. If we change a tag, then every system that uses that tag needs changing too. Every installation of openstreetmap-carto needs updating. Every customised fork of openstreetmap-carto needs updating. Every stylesheet that uses the original tag needs updating, and every cartographer needs to find the time to investigate and make the changes. Despite all this I'm going to approve the pull request, since I'm trying very hard to be maximally collaborative, but let this diatribe be both a lesson in careful reading and a warning to the next group who propose such a daft change. Congrats if you didn't skim read this bit, now back to my ranting. And every server that hosts any copy of those stylesheets needs updating. And every customer support request from a user of a map using OpenStreetMap data where their maps are missing some features needs investigating, and every manager needs to figure out where all these man hours are going. And when everyone finds out that all this hassle is not because we have a great new thing, when they find out it's just to make a trivial change to an underscore that wasn't causing any problems in the first place, will they think it's all worth it? Of course, downstream users aren't our highest priority, it is and always will be our mappers. So making tagging easy for them seems a priority, but is actually one step removed from the actual priority. The activity that we want to make easy is to map; that is, to represent features in our database. The actual tags themselves are merely an implementation detail, and play an every-diminsishing role in this, since most mappers now use systems with translateable presets. Remembering the exact character-sequences of tags is less important than it used to be, and so changing them becomes even less worthwhile. Of course, there are still valid reasons for as described above. Those of you who skimmed to the end are encouraged to go back and read this properly. |
|
Hi, Thank you back @gravitystorm for this explanatory answer, especially if you don't have too much time to spent. I merely agree to what is said above. No one argued the change is a simple thing to handle. But in the meantime, we need to look forward with the better model we have than before. Current broken things will be fixed in a better shape (regarding technical description that OSM can't ignore on several topics, it guarantees its interoperability and then its popularity) they had ever been. Good luck to find the best way to update rendering rules. Cheers. |
|
Newcomer here but I'm the user (polderrunner) that actually proposed the new substation tagging scheme including the spelling change. I'm a little bit sad to see how the discussion has developed here. It should really just have been a simple request to render the new feature "power=substation" in the same way as existing feature "power=sub_station" (and it was never suggested to remove rendering of power=sub_station at this stage). As the change can be combined as a single commit with new rendering support for 'power=plant' the implementation is not really an issue in my opinion. All the new features of the substation tagging scheme (transformers, busbars etc) probably don't belong in the main OSM map. They are really intended for more specialist maps and applications focussing on power infrastructure. |
|
@opani-dk No change of an existing tag can ever be "just ... a simple request", as I have explained in great detail above. I think you've entirely missed the consequences of what you consider to be a trivial change, and I urge you to re-read what I've written and consider how big the effects are. You say "the implementation is not really an issue" - of course it isn't, it's a patch that's about two lines long. But the change has much bigger consequences than I think that you realise. |
Kudos for that great social hack. |
|
Tagging change are needed since tags can't be completely defined when they are introduced for first time. The small experience I had myself show me it's very hard to define them completely. We can look for consistency regarding the existing features, maybe in next future but never define "fixed" things. OSM seems to be built around that main question. If the whole ecosystem isn't able to deal with it, it should be improved. Then please stop asking people who want (and actually give power, time, food, sleep, etc...) to make things better than before to don't do so just because the system itself is stuck in past. For now, if the render is updated, it would be a great victory... |
That's as true as it is irrelevant. Many and many tagging schemes are constantly introduced, changed, evolved, and deprecated in parallel, and all OSM consumers must always keep up - exchange some "trivial change" for illusive compatibility and nothing will change - all consumers will still have to keep up with other changes and everything quoted above will still happen. However, an improvement for data scheme (trivial or not) will be lost. Actually, you can't even do this exchange, as the new scheme will be used regardless, and ignoring in the style it will only make it painful both for style users (not seeing mapped features) and for mappers (confusion on what scheme to use). The only right way I see as both mapper, data consumer and active member of community is supporting new schemes as fast as possible, and sorry, but I don't see much collaboration from you here. Which is worse, I see the same even for old incorrectly supported schemes (tunnel=* for example). However, I still hope for that attitude to change. Anyway, if you approve particular #252, when should we expect it to be merged, or are there still any updates required from me? |
|
It might help to explain the history of the map style a bit here. If you submitted this wiki change say a year ago (or even 2 years ago) then there would be no chance of it being rendered at all as the old mapnik style was unmanageable and no changes were being made at all. Only with GravityStorm's work on this osm-carto-css style to manually convert it all to the new format has it been made possible to do this and only in the last few months has it been used as the rendering style on the main page of osm. There are thousands of bugs that have been submitted for the old style format that are also there on the osm-carto-css style. I imagine tunnel=* is one of those. Also there is much work to be done on many aspects of the style. Re-factoring the code and organizing it better. These are more important to get a decent structure than just adding new features with a sticky plaster approach. Introducing more changes will neglect other issues and other features that we want to add. I don't think GravityStorm is saying that no new tagging changes will ever be added to it but to consider it more. He has explained in depth about the all the other groups that could use it. Personally I think we could have these discussions at the wiki proposal stage - how will it look rendered, what issues are when it is rendered, how are editors going to implement this. Do (I see no point changing these things unless all the editors are going to change to the new format) True it is a chicken and egg situation but the simple part quickly knocking up a wiki proposal. Hooray! you have done that bit. Also I do dislike rendering multiple things on the render that mean the same thing. They stay in rendering code for years (it is not as glamorous to remove these) and there will be multiple and confusing reference to legacy tags all over the place. If you want to encourage people to start using a new tagging format and stop using an old tagging format then you only render the new one and only have the editors use the new one and the wiki says do the new one. |
|
2013/11/25 Andy Allan notifications@github.com
There is a misconception as this proposal not only changed the spelling, |
|
@dieterdreist From the opening of this issue: "and it is exactly the same as power=sub_station, except the misspelling problem" |
|
2013/11/27 Andy Allan notifications@github.com
yes, he wrote that, but it was incorrect ;-) |
|
taginfo stats as of 08.02.2014: It would be nice substations to be rendered also. |
|
Earlier this week, approximately all French substations has been renamed from sub_station to substation. http://www.openstreetmap.org/#map=18/47.82512/-3.31177 +1 with pl71 to have those objects rendered properly. |
|
Note that josm validator already (since Jan 15) treats This problem of not rendering new tags is not pretty critical. |
|
I have just submitted a pull request (pull #511 ) that adds rendering for (just) power=substation until the bigger rewrite is done. |
|
Wasn't this already complete? In the middle of his rant 5 months ago, @gravitystorm said he was approving a pull request. Did some regression occur since then? |
|
It seemed like it would be done five months ago, but nothing has changed since then. I should know, because I’ve been adding powerlines and substations in my area and the only substations that show up properly are the few with the deprecated power=sub_station tag, and I’ve changed pretty much all of them to the newer tag. The substations that I’ve tagged usually have a barrier=* tag (every substation has a fence or a wall to keep people out) and of course that’s the only thing being rendered. I thought carto was supposed to make it easier to keep the stylesheet updated with the latest tagging schemes and whatnot. Why, then, has this not been fixed? From: lest69 [mailto:notifications@github.com] Wasn't this already complete? In the middle of his rant 5 months ago, @gravitystorm https://github.com/gravitystorm said he was approving a pull request. Did some regression occur since then? — |
|
@gravitystorm I think we should prioritize this (assuming it hasn't been merged, not sure), because it shows to the rest of the community that the openstreetmap-carto project is alive, and that change is possible. I would expect that that also would increase the chance of attracting developers (while not doing anything, even if we're asked 'from the outside' repeatedly gives off the air of a dead project). The power substation changes have gotten quite a lot of attention on the tagging mailing list. There might be some minor technical issues with the proposal at the moment, but I suggest we work these out as fast as possible. |
|
It was fixed by #511 and power=substation is now rendered. |
|
Closed. |
Hi,
A new proposal has been accepted regarding power substations mapping.
It introduce a new tag, power=substation, to map such features and it is exactly the same as power=sub_station, except the misspelling problem.
power=station or power=sub_station are now deprecated but still have a strong presence on map. It will take time to move all stuff to new power=substation.
Please update your style sheet to render power=substation properly.
Additionally, you can focus on power=line + line=busbar or power=line + line=bay which represent special power lines inside substations. They may be rendered differently (with dashes or whatever) than big overhead power lines.
Finally, may you add a small lightning on every power=substation object, regardless of voltage.
Accepted proposal is here : http://wiki.openstreetmap.org/wiki/Proposed_features/Substation_refinement
Feel free to comment.
Cheers.
The text was updated successfully, but these errors were encountered: