User talk:Supaplex030

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)

Parking=street_side

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: https://github.com/openstreetmap/id-tagging-schema/pull/73

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 patch — JeroenHoek (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)

Key:disabled#Examples — Davileci (talk) 17:45, 24 June 2023 (UTC)

amenity=traffic_park

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)

Do you have it available as SVG?

Is https://wiki.openstreetmap.org/wiki/File:Cycle_barrier_single_simple.png available as SVG file? Or have you created it as a bitmap from start? Mateusz Konieczny (talk) 10:09, 10 October 2021 (UTC)

Unfortunately, I only have this as a bitmap (created with GIMP). But with Incscape or similar software you could possibly vectorise it well. If it's important, I can try it if you let me know again. --Supaplex030 (talk) 10:13, 10 October 2021 (UTC)

I suspect that https://github.com/streetcomplete/StreetComplete/issues/3361 (if implemented) will use photos, so lets not do it just in case. But for example finding/taking image clearer than https://wiki.openstreetmap.org/wiki/File:Umlaufsperre_%C3%BCberlappt_Berlin_Thomash%C3%B6he.jpg (without massive distracting shade, showing clearly two barrier) would be very useful! Mateusz Konieczny (talk) 10:53, 10 October 2021 (UTC)

Yeah, that's right. A picture like this one shown beside, but showing the full barrier could be better. If I get the chance, I can try to take a better picture. Wikimedia, unfortunately, hardly has any good pictures either [1, 2, 3]. --Supaplex030 (talk) 11:05, 10 October 2021 (UTC)

http://www.geograph.org.uk/of/bicycle+barrier also failed - https://www.geograph.org.uk/photo/6087573 is really, really busy and polluted by extra objects. I will also try to find something nearby, but there is low chance that I will manage to succeed - this kind of object is quite rare in my area and few that I know would be unsuitable due to massive number of nearby distracting objects Mateusz Konieczny (talk) 11:15, 10 October 2021 (UTC)

Missing file information

Hello! And thanks for your upload - but some extra info is necessary.

Sorry for bothering you about this, but it is important to know source of the uploaded files.

Are you the author of image File:Baumerhebung Instrumente.jpg ?

Or is it copied from some other place (which one?)?

Please, add this info to the file page - something like "I took this photo" or "downloaded from -website link-" or "I took this screeshot of program XYZ".

In case that you are the author of the image: Would you agree to open licensing of this image, allowing its use by anyone (similarly to your OSM edits)?

Would you be OK with CC0 (it allows use without attribution or any other requirement)?

Or do you prefer to require attribution and some other things using CC-BY-SA-4.0?

If you are the author: Please add {{CC0-self}} to the file page to publish the image under CC0 license.

You can also use {{CC-BY-SA-4.0-self}} to publish under CC-BY-SA-4.0 license.

Note that in cases where photo is a screenshot of some software interface: usually it is needed to handle also copyright of software itself.

Note that in cases where aerial imagery is present: also licensing of an aerial imagery matter.

Feel free to ask for help if you need it - you can do it for example by asking on Talk:Wiki: new topic.

Please ask there if you are not sure what is the proper next step. Especially when you are uploading files that are not your own work or are derivative work (screenshots, composition of images, using aerial imagery etc).

Once you add missing data - please remove {{Unknown|subcategory=uploader notified January 2022}} from the file page.

--Mateusz Konieczny (talk) 16:28, 26 January 2022 (UTC)

Missing file information

Hello! And thanks for your upload - but some extra info is necessary.

Sorry for bothering you about this, but it is important to know source of the uploaded files.

Are you the creator of image File:Map n friends.jpg ?

Or is it copied from some other place (which one?)?

Please, add this info to the file page - something like "I took this photo" or "downloaded from -website link-" or "I took this screeshot of program XYZ" or "this is map generated from OpenStreetMap data and SRTM data" or "map generated from OSM data and only OSM data" or "This is my work based on file -link-to-page-with-that-file-and-its-licensing-info-" or "used file downloaded from internet to create it, no idea which one".

Doing this would be already very useful.

Licensing - photos

In case that you are the author of the image: Would you agree to open licensing of this image, allowing its use by anyone (similarly to your OSM edits)?

In case where it is a photo you (except relatively rare cases) author can make it available under a specific free license.

Would you be OK with CC0 (it allows use without attribution or any other requirement)?

Or do you prefer to require attribution and some other things using CC-BY-SA-4.0?

If you are the author: Please add {{CC0-self}} to the file page to publish the image under CC0 license.

You can also use {{CC-BY-SA-4.0-self}} to publish under CC-BY-SA-4.0 license.

Once you add missing data - please remove {{Unknown|subcategory=uploader notified March 2022}} from the file page.

Licensing - other images

If it is not a photo situation gets a bit more complicated.

See Drafts/Media file license chart that may help.

note: if you took screenshot of program made by someone else, screenshot of OSM editor with aerial imagery: then licensing of that elements also matter and you are not a sole author.

note: If you downloaded image made by someone else then you are NOT the author.

Note that in cases where photo is a screenshot of some software interface: usually it is needed to handle also copyright of software itself.

Note that in cases where aerial imagery is present: also licensing of an aerial imagery matter.

Help

Feel free to ask for help if you need it - you can do it for example by asking on Talk:Wiki: new topic.

Please ask there if you are not sure what is the proper next step. Especially when you are uploading files that are not your own work or are derivative work (screenshots, composition of images, using aerial imagery etc).

If you are interested in wider discussion about handling licencing at OSM Wiki, see this thread.

(sorry if I missed something that already states license and source: I am looking through over 20 000 files and fixing obvious cases on my own, in other I ask people who upladed files, but it is possible that I missed something - in such case also please answer)

--Mateusz Konieczny (talk) 14:59, 23 March 2022 (UTC)

Missing file information

Hello! And thanks for your upload - but some extra info is necessary.

Sorry for bothering you about this, but it is important to know source of the uploaded files.

Are you the creator of image File:Rip baum.jpg ?

Or is it copied from some other place (which one?)?

Please, add this info to the file page - something like "I took this photo" or "downloaded from -website link-" or "I took this screeshot of program XYZ" or "this is map generated from OpenStreetMap data and SRTM data" or "map generated from OSM data and only OSM data" or "This is my work based on file -link-to-page-with-that-file-and-its-licensing-info-" or "used file downloaded from internet to create it, no idea which one".

Doing this would be already very useful.

Licensing - photos

In case that you are the author of the image: Would you agree to open licensing of this image, allowing its use by anyone (similarly to your OSM edits)?

In case where it is a photo you (except relatively rare cases) author can make it available under a specific free license.

Would you be OK with CC0 (it allows use without attribution or any other requirement)?

Or do you prefer to require attribution and some other things using CC-BY-SA-4.0?

If you are the author: Please add {{CC0-self}} to the file page to publish the image under CC0 license.

You can also use {{CC-BY-SA-4.0-self|Supaplex030}} to publish under CC-BY-SA-4.0 license.

Once you add missing data - please remove {{Unknown|subcategory=uploader notified 2022, May}} from the file page.

Licensing - other images

If it is not a photo situation gets a bit more complicated.

See Drafts/Media file license chart that may help.

note: if you took screenshot of program made by someone else, screenshot of OSM editor with aerial imagery: then licensing of that elements also matter and you are not a sole author.

note: If you downloaded image made by someone else then you are NOT the author.

Note that in cases where photo is a screenshot of some software interface: usually it is needed to handle also copyright of software itself.

Note that in cases where aerial imagery is present: also licensing of an aerial imagery matter.

Help

Feel free to ask for help if you need it - you can do it for example by asking on Talk:Wiki: new topic.

Please ask there if you are not sure what is the proper next step. Especially when you are uploading files that are not your own work or are derivative work (screenshots, composition of images, using aerial imagery etc).

If you are interested in wider discussion about handling licencing at OSM Wiki, see this thread.

(sorry if I missed something that already states license and source: I am looking through over 20 000 files and fixing obvious cases on my own, in other I ask people who upladed files, but it is possible that I missed something - in such case also please answer)

--Mateusz Konieczny (talk) 04:10, 26 May 2022 (UTC)

Licence on Key:cycle_barrier:installation images?

Hi, it seems that images uploaded by you at Key:cycle_barrier:installation are marked as CC-BY-SA 4.0, but lack the author attribution, which is ALWAYS required. If those pictures are created by you, can you modify tag to {{CC-BY-SA-4.0-self}} from existing {{CC-BY-SA-4.0}}? Or add correct author, by using {{CC-BY-SA-4.0|Author name}}?

TIA, --mnalis (talk) 20:15, 4 September 2022 (UTC)

Thanks, I have just modified the licence information. I'm sure there are more images of mine that are affected by this. Wasn't there an overview page somewhere (by Mateusz?) where the affected images were automatically collected? --Supaplex030 (talk) 20:16, 4 September 2022 (UTC)

Thanks! Those seem to be put into category https://wiki.openstreetmap.org/wiki/Category:Attribution_not_provided_in_CC_license_template_which_requires_attribution (and others) but I don't know how to search for specific user inside those. Feel free to remove this (and other) resolved sections from your user talk page --mnalis (talk) 01:29, 5 September 2022 (UTC)

Im Street parking Schema wird Schlüssel restriction=* nicht ausschliesslich als Suffix verwendet?

Hallo Supaplex030, bist Du >hier< im Abschnitt "Tagging" auf die Idee gekommen den bestehenden Schlüssel restriction=* (der einzeln bereits als Secondlevel Schlüssel bei den Abbiegebeschränkungen Relation:restriction benutzt wird) auch bei den Parkbeschränkungen einzeln (also nicht als Suffix) einzuführen? Könnte man im Street parking Schema ausschliesslich beim *:restriction=* bleiben? Das stand so wohl auch nicht im Proposal:Street_parking_revision, oder übersehe ich da etwas? Schöne Grüsse MalgiK --MalgiK (talk) 06:49, 22 January 2024 (UTC)

Hallo @MalgiK,
in der Tat wird restriction=* im Kontext Street Parking ohne Präfix verwendet, wenn die Parkmöglichkeit als separates Objekt gemappt wird (siehe Abschnitt Separately mapped parking spaces and areas). Ein Hauptziel des Proposals war es, die Tags an separat und nicht separat gemappten parking features zu synchronisieren, sodass jeweils identische Tags verwendet werden – entweder mit (bei nicht separat gemappten features) oder ohne (bei separat gemappten) parking:<side>-Prefix. Das dadurch eine homonyme Verwendung zu turn restrictions entsteht, scheint mir kein Problem zu sein - oder wo siehst du Konflikte?
restriction=* kann bzw. sollte bei separat gemappten Parkplätzen also auch weiterhin so verwendet werden, wie es auf der Seite dokumentiert war. Habe eben gerade erst entdeckt, dass du die parking-Inhalte gelöscht hast – es wäre gut, sie wieder herzustellen, ggf. unterhalb der jetzigen turn-restriction-Inhalte als zweites Kapitel.
lg, Alex Supaplex030 (talk) 14:39, 22 January 2024 (UTC)

Gerade erst gelesen, scheinbar hat der nachträgliche-Ping nicht funktioniert.

[...] Konflikte?: Also auf der Seite Homonymous_keys#Disadvantages werden die Nachteile augeführt. --MalgiK (talk) 21:25, 28 February 2024 (UTC)