User talk:Supaplex030

From OpenStreetMap Wiki
Jump to navigation Jump to search

Vote on pumping proposal

Hi Supaplex030 and thank you for your comment on Proposed_features/Pumping_proposal. As I don't want to oversize voting, let's continue the discussion here. You mention an impressive work about emergency water pumps in Berlin I wasn't aware of. There was two important points to solve with in proposal:

  • Currently, pump=* only regards drivers, not pumps, which seems too restrictive to me as the same piston pump could be powered or not. We use one word in place of another concept. The usage you made of pump:style=*, pump:status=* are more conform to the definition of the word pump and replacing current pump=* with mechanical_driver=* can be more correct from that point of view.
  • Even if pump=powered sounds simpler, it can cause harm: impossible to know if the pump needs electricity or gasoline to be restored in case of environmental crisis or outage. However, I think mechanical_driver=powered would be ok to add in the list to preserve the simpler distinction between manual and powered, waiting for more accurate information about that. How would you feel about it? Fanfouer (talk) 16:10, 21 November 2020 (UTC)
Sorry for my late answer. I still think that keeping pump=* and renewing/introducing pump:driver=*, pump:coupling=* and pump:type=* (or a similar term - you know more about that; with the values you have in mind for pump=*) would be a good compromise. pump=* is a simple, pragmatic (and above all: approved and in use) distinction that all mappers can make. pump:driver=*, pump:coupling=* and pump:type=* are details based on that, which can (and should!) be added, but I can only expect a few mappers to be able to recognize them or take the time to capture them.
And, yes, of course it is interesting to know what driver, coupling, fuel etc. is used to run a pump. I am also willing to record such details if I notice them or have time to record them. It seems to me, however, not to correspond to the mapping reality of most mappers, who would classify a detail like the power/mechanism of a pump into just one of a few categories (e.g. manual vs. powered) at a glance, but who can't investigate further and rather don't capture this information at all (if the scheme is too complex).
Perhaps the most important thing in the end is that there is an accepted way at all to systematically capture the information you propose, even if the scheme is not as "perfect" as it might be if we were to restart OSM from the very beginning (which is often a problem in OSM when you have to include historically grown, sometimes inconsistent schemes). --Supaplex030 (talk) 12:33, 24 November 2020 (UTC)
Thank you for this answer, it's not late at all.
First of all, pump=* is not approved, it has not been reviewed like we are doing now. It was introduced in 2013 but used since circa 2011. If I was asked to vote it, I would certainly have opposed it.
You know, I was simultaneously blamed for long-hard-to-remember-complex keys names without namespace so I avoid them unless required.
Drivers and couplings aren't specific to pumps, there is no point to force them under pump=*.
Looking for consensus is significant however not the only condition for me. Specifically here, I'm not really convinced it would be a good idea to introduce a new key beside pump=*. That makes the final choice harder to make. Fanfouer (talk) 21:32, 24 November 2020 (UTC)


It looks like our proposal was approved with a good deal of support! I'll port bits and pieces of it to the relevant wiki pages. Thanks for the fruitful collaboration! — JeroenHoek (talk) 10:31, 29 November 2020 (UTC)

Nice, congrats! It was a great pleasure to work with you successfully on this proposal :)
I'll probably find some time this evening, if there are still "implementations" to be done.
Two remarks: For the entry on the amenity=parking page, I would like to add a note like "consider using parking:lane if the parking areas extend along a longer section of a street", for the mappers who are not interested in detailed mapping -- similar to the suggestion in the proposal.
I also suggested the tag {parking:street_side=* (parallel/diagonal/perpendicular). Even though this suggestion is in the proposal, I would like to change it to parking:orientation=*}, because this spelling would be more logical and usable independent of our value. Apart from me there is only one mapper who has used it in a few cases so far. Since this tag is only a side note in our proposal, I don't think it is a problem to change it afterwards.
What do you think? Where else could I do something tonight? --Supaplex030 (talk) 11:11, 29 November 2020 (UTC)
Both the note and the tag-name sound good to me. Could you do the bits related to parking:lane=*? I'll see if I can move some of the auxiliary documentation to the wiki as well; things such as the definition for layby and at least some tentative notes on lane. These may not be perfect, but its better than what currently exists. Also finding suitable places for some of the graphics and photos we've gathered. I'll probably work on some bits during the coming week. JeroenHoek (talk) 11:22, 29 November 2020 (UTC)
I'll do @bits related to parking:lane! Thanks for your work so far! --Supaplex030 (talk) 11:27, 29 November 2020 (UTC)
I have opened a pull request for an iD preset:
I'll have a look at the parking:lane part of that later; that seems a bit more complex. JeroenHoek (talk) 19:18, 29 November 2020 (UTC)
Continued to work on the implementation and added entries to all wiki pages (including German) where references to street_side exist or should exist. I also added more information on the main page (taken from the proposal). I think on the parking:lane=* page it is already done with the few changes I made there (background explanations could be found on the proposal page). Or what do you think? (Where) Do you see a need for further work? I have also already converted hundreds of parking areas and parking lanes around Berlin :) --Supaplex030 (talk) 23:29, 29 November 2020 (UTC)
It looks like proper support for parking:lane=* is stuck on this issue in editor iD. Ah well, not much I can do about that I'm afraid. I hope they'll pick up my pull request for amenity=parking though. There is a preset for parking:lane=* on the JOSM wiki that can be installed from within JOSM; I've edited it to add street_side and remove layby. I'll see if I can submit a patch to JOSM for the parking values in its built-in preset for amenity=parking next.
I've also given parking=layby and parking=lane their own pages based on our understanding of their use. It's not ideal, but they are in effective use, so we might as well document them enough to help mappers choose the right values. Does that look alright to you?
I think we've got most of it by now. I'll archive the proposal page as well as per the proposal guidelines. — JeroenHoek (talk) 18:03, 2 December 2020 (UTC)
JOSM patchJeroenHoek (talk) 19:20, 2 December 2020 (UTC)
I very rarely use presets (and ID Editor) and I'm not realy a developer so I'm not very in to this discourses...
No problem, I'll handle these. — JeroenHoek (talk) 18:33, 3 December 2020 (UTC)
On page parking=lane, I think we should emphasise more that parking:lane=* is the better/easier choice for this in most cases (and perhaps make a reference to area:highway=*?). I'll write this down on my to-do list...
Agreed, feel free to change the wording for parking=lane. I figured I'd start with the most neutral factual statements first and let it develop from there. — JeroenHoek (talk) 18:33, 3 December 2020 (UTC)
Apart from that, I'm currently experiencing a few conflicts in the implementation of our scheme in our local community: One of the two opponents of our proposal comes from my town. Next week there will be a local mapper meeting, where we will discuss how to proceed... But the arguments are actually based on "rendering spam of blue P symbols" and are therefore not really "valid" (especially since this problem was one of the bases for our proposal)... --Supaplex030 (talk) 16:30, 3 December 2020 (UTC)
Ugh, that sounds tiresome. Sorry to hear that. Good luck with the meeting. But yes, it should help to emphasize that rendering can be fixed as a result of the proposal, although convincing the Carto maintainers is a future challenge all in itself. If your critics feel strongly about the rendering, why not ask them to back any rendering proposal that achieves these goals in due time? Which reminds me that your rendering examples deserve a place on parking=street_side too. — JeroenHoek (talk) 18:33, 3 December 2020 (UTC)


I am not planning to put it to vote, as I worry that even best value will fail.

And I prefer to have abandoned proposal and de-facto value over tagging rejected in a vote.

But if you think that one of this values is likely to success in proposal - feel free to make your own with content copied from this one (copy as much as you want) Mateusz Konieczny (talk) 19:55, 25 December 2020 (UTC)