Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Power substation rendering #230

Closed
flacombe opened this issue Oct 15, 2013 · 45 comments

Comments

Projects
None yet
@flacombe
Copy link

commented Oct 15, 2013

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.

@pnorman

This comment has been minimized.

Copy link
Collaborator

commented Oct 15, 2013

taginfo stats:
power=substation: 243
power=sub_station:100725

Looks pretty clear what the accepted tag is.

@flacombe

This comment has been minimized.

Copy link
Author

commented Oct 15, 2013

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.

@pnorman

This comment has been minimized.

Copy link
Collaborator

commented Oct 15, 2013

As you can see here : http://wiki.openstreetmap.org/wiki/Tag:power%3Dsub_station, sub_station is now a deprecated value for power=*.

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.

All features with this value will be moved to power=substation.

Not on the basis of the wiki page vote. A mechanical edit requires consultation beyond just the wiki or the tagging@ list.

@flacombe

This comment has been minimized.

Copy link
Author

commented Oct 15, 2013

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.
Users will change values one by one by analysing context.

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.

@dieterdreist

This comment has been minimized.

Copy link

commented Oct 15, 2013

2013/10/15 fanfouer notifications@github.com

It's pretty hard work to bring consistency and good spelling in tag
values, massive re-tag is not what it's planned.
Users will change values one by one by analysing context.

New value should be rendered the same as the old,

yes, I agree, otherwise you would make the substations disappear (a feature
that already was there on the main map) when following the new approach,
which would obviously make it almost impossible to make the change slowly.

cheers,
Martin

@compdude

This comment has been minimized.

Copy link

commented Oct 16, 2013

@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.

@RussNelson

This comment has been minimized.

Copy link

commented Oct 18, 2013

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.

@compdude

This comment has been minimized.

Copy link

commented Oct 18, 2013

But the new way of spelling it is documented on the wiki. The old way of
spelling it is listed as being deprecated, with encouragements to use
power=substation rather than power=sub_station. The rendering needs to stay
up with the latest times. It's already been approved. Although it was NOT
my decision and I didn't even vote, I do endorse the decision made because
substation is normally spelled as one word, not sub station. Saying "sub
station" is wrong and I've never seen it written that way.

Comparing it to railways is comparing apples to oranges because both words
mean the same thing and both are correct ways of referring to a train track.

I really don't see why there's such opposition on here to adding just one
single tag
, which is mentioned the wiki and endorsed by many more people.
I hate how the general community culture on OSM has to be so hostile, too.
If you guys really don't like this decision that was made, fine then, go
post a message on the tagging mail list.

On Thu, Oct 17, 2013 at 11:39 PM, Russ Nelson notifications@github.comwrote:

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.


Reply to this email directly or view it on GitHubhttps://github.com//issues/230#issuecomment-26574991
.

@compdude

This comment has been minimized.

Copy link

commented Oct 18, 2013

I should repeat what @fanfouer said above:
"This proposal has been discussed on tagging@ and talk@ mailing list for months."

I don't see why this is such a controversial change. Nuff said.

@dieterdreist

This comment has been minimized.

Copy link

commented Oct 18, 2013

2013/10/18 Russ Nelson notifications@github.com

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.

the meaning and intended usage of the tag was modified, so a new spelling
makes sense. It wasn't for the misspelling that this tag was changed, but
it was an occasion to get the spelling right (and keep the distinction
old-meaning / new meaning by using slightly different tags).

cheers,
Martin

@vincentdephily

This comment has been minimized.

Copy link

commented Oct 18, 2013

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.

@dieterdreist

This comment has been minimized.

Copy link

commented Oct 18, 2013

2013/10/18 vincentdephily notifications@github.com

While I don't have the time to keep up with Tagging@ and find the taginfo
stats more important anyway,

taginfo is very nice to see which tags are used often and which aren't, but
it doesn't tell you anything about the meaning of these tags.

@vincentdephily

This comment has been minimized.

Copy link

commented Oct 18, 2013

taginfo is very nice to see which tags are used often and which aren't, but it doesn't tell you anything about the meaning of these tags.

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.

@compdude

This comment has been minimized.

Copy link

commented Oct 18, 2013

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.

@compdude

This comment has been minimized.

Copy link

commented Oct 21, 2013

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.

@compdude

This comment has been minimized.

Copy link

commented Nov 2, 2013

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.

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

commented Nov 3, 2013

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)?

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

commented Nov 10, 2013

@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.

@AMDmi3

This comment has been minimized.

Copy link

commented Nov 18, 2013

JFYI, over 3 weeks number of power=substation uses had increased tenfold: http://taginfo.openstreetmap.org/tags/?key=power&value=substation

@flacombe

This comment has been minimized.

Copy link
Author

commented Nov 19, 2013

Thanks @AMDmi3 @math1985 @compdude and others for your comments.

For god sake, how many noise we'll have to make to see this issue closed ?

@gravitystorm

This comment has been minimized.

Copy link
Owner

commented Nov 19, 2013

@fanfouer More "noise" would be extremely unwelcome.

@jremillard

This comment has been minimized.

Copy link

commented Nov 19, 2013

@fanfouer I think they are doing just bug fixes right now.....

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

commented Nov 20, 2013

@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 :).

@Rovastar

This comment has been minimized.

Copy link
Contributor

commented Nov 20, 2013

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.
Really I imagine this could be coordinated better. Not just we have a done wiki xyz change therefore you must do a carto map change straight away. Really I cannot see why this cannot be co-ordinated with a mechanical edit as well. If all the tags were changed/to be changed on a set date period then it is more likely that the carto implemented.

It makes it sound like a demand and that is no way to get things done in a volunteer community.

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

commented Nov 24, 2013

I have invited @gravitystorm by e-mail to give his opinion on this issue.

@gravitystorm

This comment has been minimized.

Copy link
Owner

commented Nov 25, 2013

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. landuse=farm was a great example, where using farmland and farmyard not only help english-speaking contributors, but also causes less confusion when translated.

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 sub_station to substation has to be one of the lowest-net-benefit changes I have seen to date, or could even imagine. It does not make it easier to translate; it adds no clarity to the meaning of the tag; and the spelling mistake that it corrects is almost indistiguishable from change for change's sake.

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.

@flacombe

This comment has been minimized.

Copy link
Author

commented Nov 25, 2013

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.
One thing is missing then : the power substation refinement proposal wasn't only composed of sub_station to substation change. The whole thing need this change to provide a fully consistent model regarding all facilities where power is transformed. A work which hadn't been completely done before. Even if it's at a tiny detail scale, consistency is a whole package matter.
It definitely improves both mapping and consuming.

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.
I'm not afraid to edit thousand of features, if it's done in sustainable way, that's why I'm here.

Good luck to find the best way to update rendering rules.

Cheers.

@opani-dk

This comment has been minimized.

Copy link

commented Nov 25, 2013

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.

@gravitystorm

This comment has been minimized.

Copy link
Owner

commented Nov 26, 2013

@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.

@MaZderMind

This comment has been minimized.

Copy link

commented Nov 26, 2013

Those of you who skimmed to the end are encouraged to go back and read this properly.

Kudos for that great social hack.

@flacombe

This comment has been minimized.

Copy link
Author

commented Nov 26, 2013

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.
Debates should go on ideas, not on the ability of the system to handle such basic changes.

For now, if the render is updated, it would be a great victory...

@AMDmi3

This comment has been minimized.

Copy link

commented Nov 26, 2013

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.

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?

@Rovastar

This comment has been minimized.

Copy link
Contributor

commented Nov 27, 2013

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)
Once you have the buy-in ALL of the communities (editors, renders, etc) then you should go for the change. The wiki says tag it as x where it used to be y, the editor tags it as y, the render displays it if y (and the proposal here is to also display x).

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.

@dieterdreist

This comment has been minimized.

Copy link

commented Nov 27, 2013

2013/11/25 Andy Allan notifications@github.com

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
sub_station to substation has to be one of the lowest-net-benefit changes
I have seen to date, or could even imagine. It does not make it easier to
translate; it adds no clarity to the meaning of the tag; and the spelling
mistake that it corrects is almost indistiguishable from change for
change's sake.

There is a misconception as this proposal not only changed the spelling,
but also extended the meaning (what were 2 classes before according to size
/ voltage, i.e. values "station" and "sub_station", regardless of the
linguistic meaning of station (place to produce electricity aka power
station) both used for substations now becomes both "substation").

@gravitystorm

This comment has been minimized.

Copy link
Owner

commented Nov 27, 2013

@dieterdreist From the opening of this issue: "and it is exactly the same as power=sub_station, except the misspelling problem"

@dieterdreist

This comment has been minimized.

Copy link

commented Nov 27, 2013

2013/11/27 Andy Allan notifications@github.com

@dieterdreist https://github.com/dieterdreist From the opening of this
issue: "and it is exactly the same as power=sub_station, except the
misspelling problem"

yes, he wrote that, but it was incorrect ;-)

@pl71

This comment has been minimized.

Copy link

commented Feb 8, 2014

taginfo stats as of 08.02.2014:
power=sub_station: 104 605
power=substation: 9 063

It would be nice substations to be rendered also.
So we have 9 063 important objects not rendered.

@flacombe

This comment has been minimized.

Copy link
Author

commented Feb 8, 2014

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.

@AMDmi3

This comment has been minimized.

Copy link

commented Feb 22, 2014

Note that josm validator already (since Jan 15) treats power=sub_station and power=station as deprecated. power=substation and power=substation/power=plant are suggested as alternatives.

This problem of not rendering new tags is not pretty critical.

@DeeHants

This comment has been minimized.

Copy link
Contributor

commented Apr 29, 2014

I have just submitted a pull request (pull #511 ) that adds rendering for (just) power=substation until the bigger rewrite is done.
Any comments welcome.

@lest69

This comment has been minimized.

Copy link

commented May 1, 2014

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?

@compdude

This comment has been minimized.

Copy link

commented May 2, 2014

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]
Sent: Thursday, May 1, 2014 1:48 PM
To: gravitystorm/openstreetmap-carto
Cc: compdude
Subject: Re: [openstreetmap-carto] Power substation rendering (#230)

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?


Reply to this email directly or view it on GitHub #230 (comment) . https://github.com/notifications/beacon/3644272__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxNDU5NjQ5MCwiZGF0YSI6eyJpZCI6MTg0MTgzMjd9fQ==--0a86c6327b093db883c0858f81c7f7c7d3698ff9.gif

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

commented May 15, 2014

@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.

@matkoniecz

This comment has been minimized.

Copy link
Collaborator

commented Jun 30, 2014

It was fixed by #511 and power=substation is now rendered.

@matthijsmelissen

This comment has been minimized.

Copy link
Collaborator

commented Jun 30, 2014

Closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.