User talk:Fkv

File:Traunstein franzosenstein.jpg und ff.

Hallo, kennst du die folgende Seite: DE:Wiki Translation#Bilder im Wiki?

Wenn Du eigene Bilder gemacht hast, lade sie nach Commons hoch (nicht hier im Wiki), gib ihnen möglichst eine PD-Lizenz, und binde sie von dort im Wiki ein - so stehen sie weltweit auch für andere Projekte zur Verfügung.

Daher würde ich mich sehr freuen, wenn du das o.g. Bild und ff. in der  Category:Bad Traunstein bei wikimedia commons hoch laden würdest. Wenn du Hilfe brauchst, meld dich. Danke & Gruß --Reneman (talk) 21:53, 9 July 2013 (UTC)

Du kennst ja viele Tricks, auch die Liste meiner eigenen Uploads hatte ich bisher vergeblich gesucht. Alle Bilder nochmal hochzuladen ist mir zu viel Aufwand, und eine PD Lizenz kommt nicht in Frage, höchstens CC-BY-SA - damit meine Urheberschaft nicht unterschlagen wird. Aber beim nächsten Mal werde ich mir das Commons sicher anschauen. --Fkv (talk) 17:36, 10 July 2013 (UTC)

Keine Sorge, die standartmäßige Lizens bei wikimedia commons ist "Namensnennung, Weitergabe unter gleichen Bedingungen 3.0" CC BY-SA 3.0

Wenn du das Uploadtool benutzt (vorher login), kannst du alle Dateien in einem rutsch hoch laden. Wenn du den gleichen Dateinamen benutzt, mußt du hier im Wiki die Seiten nicht einmal verändern. gruß --Reneman (talk) 18:36, 10 July 2013 (UTC)

Hallo, da du an der Diskussion teilgenommen hast möchte ich dich darauf hinweisen, daß auf http://wiki.openstreetmap.org/wiki/Proposed_features/pasture das Voting eingeleitet ist. --Segatus (talk) 17:35, 27 August 2013 (UTC)

Objekt mit Koordinaten einfügen

KZ-Denkmal

Hallo Fkv, als Anfänger habe ich die Frage, wie ich ein einzelnes Objekt, dessen Koordinaten (z.Bsp. aus Wikipedia) ich habe ohne GPX file o.ä. einfach in die Karte einfügen kann. danke K@rl (talk) 14:00, 27 December 2014 (UTC)

KOnkret ich möchte das nach dem Foto, dass die Koordinaten hat, eintragen. gruß K@rl (talk) 14:10, 27 December 2014 (UTC)

Das kommt darauf an, welchen Editor (JOSM, Merkaartor, Potlatch, ID) du verwenden willst. Ich bevorzuge Merkaartor, da setzt du einen Node ungefähr an diese Stelle und kannst dann die Koordinaten noch auf die genauen Werte ändern (es gibt Eingabefelder dafür). Getaggt wird es historic=memorial. Grundsätzlich sollte man vorsichtig sein, wenn man Koordinaten von fremden Quellen übernimmt. Die Koordinaten können falsch oder ungenau sein. Am besten vor Ort oder mittels Orthofoto überprüfen, bzw. source:position=Wikipedia o.ä. setzen. --Fkv (talk) 15:43, 27 December 2014 (UTC)

Bisher kenn ich nur ID mit JOSM bin ich nihct recht voran gekommen. Zu diesen Koordinaten speziell habe ich Vertrauen, da sie von mir selbst sind ;-). Zu den anderen Denkmälern innerhalb Österreichs auch, da ich prinzipiell fast alle der Benutzer kenne, die vor Ort waren und auch fotografiert haben und die wir in ZUsammenarbeit mit dem Bundesdenkmalamt erruiert haben. Wo Fehler sind, wurden sie durch unsere Leute aufgezeigt und das BDA hat sogar Bescheide korrigiert. --aber danke K@rl (talk) 21:18, 27 December 2014 (UTC)

In ID finde ich auch keine Möglichkeit, explizite Koordinaten zu setzen. Also wird es nur 3 Möglichkeiten geben: Feature Request an die Entwickler, oder den Punkt nach Luftbild setzen, oder einen anderen Editor verwenden. --Fkv (talk) 09:10, 28 December 2014 (UTC)

ICh wollte JOSM aufrufen, der lässt sich aber bei mir jetzt komischerweise nicht starten und bringt nur Fehlermeldung, dass er nicht läuft :-( --K@rl (talk) 09:12, 28 December 2014 (UTC)

Auch wenn ich JOSM strate funkt der Übergang von OSM nicht man muss alles einzelnen laden - etwas mühsam ;-) für einen Anfänger erst recht --K@rl (talk) 09:25, 28 December 2014 (UTC)

Wegen solcher Probleme mit JOSM verwende ich lieber Merkaartor, aber auch an dem muss man erst mal ein paar Konfigurationen vornehmen, damit man gut damit arbeiten kann. --Fkv (talk) 09:37, 28 December 2014 (UTC)

Na dann werde ich den einmal installieren - lass ma uns überraschen - aber danke in der Zwischenzeit. --gruß K@rl (talk) 09:51, 28 December 2014 (UTC)

Nochmals danke, das Denkmal ist laut Koordinaten drin :-) --gruß K@rl (talk) 10:06, 28 December 2014 (UTC)

Defacto tag status

You changed the status of Tag:leisure=firepit from Defacto to In use with the comment status corrected. Defacto is documented on Template:ValueDescription, what is wrong about it? --phobie m d 07:39, 1 November 2015 (UTC)

My reasons were:

1) Most "de facto" features I have come across have >100K uses. leisure=firepit has only 3583, and the number was even less back in March when I made the change.

2) Alternative tags such as amenity=bbq are also in widespread use for firepits. I have been using that tag for dozens of firepits myself, simply because it was the best matching tag I found in map features. There was no leisure=firepit in the wiki at that time. Now leisure=firepit may be a better match, but still it is not the only tag in use, hence far from "de facto".

I raised the inuse/defacto issue in the tagging mailinglist last April. Marc Gemis replied: «As others have pointed out on this mailing list before, the actual number of items that can be tagged with a certain tag matters. So in case there are only 600 items in the whole world of that "thing", it is de-facto. If there are e.g. 1.000.000 such "things", it's more "inuse" than "de-facto"» (He was referring to an example tag with 600 occurences in OSM.) According to this rule, leisure=firepit is only "in use", because there are only 3583 leisure=firepit in OSM, while millions exist in the real world. Others expressed different opinions in that mailing list thread, but whatever rule or formula you take, leisure=firepit will most certainly not qualify for "de facto".

--Fkv (talk) 18:46, 1 November 2015 (UTC)

You reverted] the garden specification proposal from "defacto" to "proposed", saying proposals can't be "de-facto" approved by usage, but it is clearly the case here. No voting can change anything for tags that are used more than 50 000 times, these tags are there. Where do you get from that proposals can't be "de-facto" approved? --Dieterdreist (talk) 08:54, 7 February 2019 (UTC)

You have to distinguish tag status and proposal status. A tag does not even need a proposal to become defacto. Also, there can be multiple proposals for the same tag. In that case, would you set all proposals to defacto status? Also keep in mind that actual usage may differ in details from proposed usage. Examples include site relations (the proposal changed significantly over time even when the relation type was already in wide use) and Proposed features/information (most of the tags have become defacto but the access tags on guideposts are disputed to say the least). BTW: Do you remember you've announced a second vote to come on the bottom of the proposal page? How's your working progress on that? --Fkv (talk) 11:43, 7 February 2019 (UTC)

Actually, while a tag could have multiple proposals, it isn't something that really occurs, only in very rare exceptions. In these cases, if none of them was voted, you would have to look what the proposal defines and how the tag is actually used on the map. I would not set a proposal to "de-facto" just because the name of the tag is the same, but the proposal defines something different from the defacto use. If any of the proposals were approved, you would probably not add defacto to the other proposals, but it still completely depends on the actual usage of the tag. Old proposals (imagining here a tag that had its definition evolve with the time) should be archived anyway, and the current feature page (ideally) says what the current meaning is, not the proposal, approved or not.
WRT the second vote, I had seen this now as well, had forgotten about it, at some point I thought it would not be needed any more as the tag was already widely used.--Dieterdreist (talk) 19:29, 7 February 2019 (UTC)

One example for tags with multiple proposals is addr2:*/addrN:*. They differ in details, and I wrote one of the proposals and rewrote it later... When you think that your proposal is not needed any more, I suggest you set the status to rejected or abandoned and focus on documenting current usage on the feature page. Let's leave it over to historians to analyze how much of the original proposal made it into past and current usage. --Fkv (talk) 01:05, 9 February 2019 (UTC)

I do not think setting a proposal about a tag which is now in use in the proposed way, to "rejected" or "abandoned", especially when there wasn't a voting. It could of course remain "proposed", but as it is already in established use, this would not be the most helpful description. I would suggest that in cases where several proposals propose the same tags (something I would try to avoid as a proponent), we try to get clarity through voting on them (it would not solve the issue though if both proposals get approved). --Dieterdreist (talk) 14:02, 21 February 2019 (UTC)

As to "there wasn't a voting": There actually was (from 2010-06-03 till 2011-11-11), and it was rejected, and the status was set accordingly. So the proposal was history and you could have left it alone... There are actually 2 versions of that proposal: The original proposal, which was rejected; and your improved version, which you forgot about, so its status would be "abandoned". As you never included yourself as a proponent, I think that the original version is more relevant to the status.

Concerning clarity by voting on multiple proposals: In my example, there are 3 similar proposals. If we let vote on all of them, the chance to get exaclty one of the approved is only 1/8. And there's a chance that all of them are voted down even though the tags are in use (same as happened with the garden type proposal). --Fkv (talk) 14:14, 22 February 2019 (UTC)

Förderbänder

Halo Friedrich,

ich finde ich deinen Vorschlag goods_conveyor unterstützenswert. Er wird nach TagInfo auch schon etwa 1000x verwendet. Wie kann man erreichen, dass er auch gerendert wird?

Teilweise wird railway=monorail verwendet, um eine Anzeige zu erzwingen, aber das gefällt mir nicht.--Kopiersperre (talk) 13:05, 8 December 2015 (UTC)

Das hängt davon ab, in welcher Karte du sie gerendert haben willst. Für die Standardkarte kannst du auf [1] unter "Issues" -> "New Issue" den Wunsch äußern und diskutieren. --Fkv (talk) 14:07, 8 December 2015 (UTC)

Einbindung in ein Wiki

Hallo Fkv, wir hatten bereits vor einiger Zeit Kontakt. In der Zwischenzeit ist das RegiowikiAT gewachsen und ich habe zahlreiche Einbindung von OSM, vor allem bei allen Gemeinden in Österreich. Auch Dromedar hat mich da an dich verwiesen, dass du mir bei meinem Ansinnen helfen könntest. Ich habe im Regiowiki die OSM Karten eingebunden siehe Linz auf RAT. Ich möchte aber auch als Ergänzung Mapire, das auch als Basis OSM hat miteinbinden. Das würde dann so bei Matricula Online ausschauen. Vielleicht siehst du da auch eine Möglichkeit - indirekt ist da ja OSM auch wieder mitbeteiligt ;-) -- danke im Voraus K@rl (talk) 13:01, 7 March 2018 (UTC)

Hast du es inzwischen herausgefunden? Ich habe lang nicht geantwortet, weil ich es selber nicht weiß und keine falsche Auskunft geben will. Ich kann nur die Javascripts und Links analysieren, aber das artet zu einer langwierigen Tüftelei aus, vor allem wenn man es dann noch testen bzw. selber zum Laufen kriegen will. Erst mal musst du dich entscheiden, wie du die Karte eingebunden haben willst: Mit Openlayers (wie auf deiner Linz-Seite) oder mit Leaflet (kein Beispiel) oder mit ArcGIS Mapview (wie auf mapire.eu, dort ist aber zusätzlich die Google-API eingebunden, da blicke ich nicht durch) oder als Iframe (wie auf der Kirchen-Seite). Beachte, dass auf der Kirchen-Seite keine Controls (Icons +/- für Zoom-in/out, usw.) vorhanden sind. Außerdem bieten Openlayers, Leaflet usw. die Möglichkeit, alle auswählbaren Karten als Layers in einem einzelnen Kartenausschnitt bereitzustellen (mit der Möglichkeit, zwischen den Layers umzuschalten), während die Lösung mit den Iframe erfordert, jede Karte separat für sich anzuzeigen.

Die Mapire-Website holt eine Konfiguration für die Layers aus http://mapire.eu/srv/json/cadastral/cadastral.json, aber das kann man anscheinend nicht unverändert in Openlayers übernehmen, denn das Geo-JSON im Beispiel auf https://openlayers.org/en/latest/examples/geojson.html sieht ganz anders aus. Aber offensichtlich nutzt+bietet Mapire einen Tile-Server, und somit sollte es möglich sein, die Tiles irgendwie in Openlayers einzubinden.

Die Lösung mit dem Iframe sieht vergleichsweise einfach aus, es wird nur ein Frame mit src=http://mapire.eu/en/map/cadastral/embed/?bbox=... eingebunden, aber die Werte in der bbox sind nicht in Grad, sondern irgendwas Seltsames. Wenn wir das Koordinatensystem herausfinden, sollte es leicht sein, die Koordinaten mittels Proj4 umzurechnen. Die Möglichkeit, einen Marker zu setzen wie in Openlayers usw., scheint in der Iframe-Lösung zu fehlen.

--Fkv (talk) 19:39, 7 May 2018 (UTC)

Ich habe versucht, mich da bei Matricula schlau zu machen, da bekam ich aber eher die Meinung zu hören, ich sollte es lizenztechnisch bleiben lassen. Und nachdem es eh nicht mit dieser umrechnung so einfach scheint, habe ich es bis auf weiteres wirklcih bleiben lassen. aber danke der Nachfrage. --lg K@rl (talk) 20:35, 7 May 2018 (UTC)

Proposed features/admin title

Hallo, 2015 bist Du mit deinem Proposal grandios gescheitert, das von dir erkannte Problem ist damit natürlich nicht aus der OSM-Welt und gerade wieder Thema in DE-Forum

https://forum.openstreetmap.org/viewtopic.php?id=65408

Grüße von Jo Cassel (talk) 16:38, 1 March 2019 (UTC) (Der dir eine gewisse Genugtuung gönnt ;-)

Discardable

About https://wiki.openstreetmap.org/w/index.php?title=Tag:site_type%3Dbigstone&diff=1764913&oldid=1764902

Note that Discardable tags has specific meaning. site_type is not automatically discarded by any editor at this moment Mateusz Konieczny (talk) 08:03, 26 March 2019 (UTC)

I don't care what editors do with that information. I made the change to keep the wiki clean. A tag that is not in use should not be documented as "in use". If you have a better suggestion than "discardable", let me know. --Fkv (talk) 09:11, 26 March 2019 (UTC)

PS: I see that you changed that page before starting this discussion. This is the wrong sequence. If you want to change something, discuss it first, and only change it if there are no objections. Please undo your change. Otherwise I'll ask a wiki admin to do it. --Fkv (talk) 09:22, 26 March 2019 (UTC)

"If you want to change something, discuss it first, and only change it if there are no objections." Wikis are not working in this way. Feel free to contact admins, but note that you can also edit it. This tag is in use (quite low), it is not marked as "de facto" indicating tag in a significant use. And "discardable" was simply wrong, as no editor has this tag on list of discardable tags. Mateusz Konieczny (talk) 10:16, 26 March 2019 (UTC)

You are misunderstanding the definition of the "discardable" status. It means that "the OpenStreetMap community have found [the tag] not to be useful", not that certain editors have actually discarded the tag. This is only the next step. First comes documentation, then the implementation in editors. It's not even possible that the status refers to implementation in editors, because - as the status definition page emphasizes - "each editor has its own list of automatically discarded tags".

And no, a tag with 73 instances is not "in use" when a synonym has more than 100x more instances. If 73 instances would qualify for an "in use" status, you could make feature pages with in-use status for all kinds of misspelled tags and other tagging mistakes such as amenity=null (5385 instances) or building="roof=permanent" (778 instances). --Fkv (talk) 11:05, 26 March 2019 (UTC)

First, if anything site_type would be changed to a different tag, not silently deleted. Second, tag that is not actually discarded by any editor is not yet discardable, at most proposed to be discardable Mateusz Konieczny (talk) 12:32, 26 March 2019 (UTC)

Your first sentence does not make any sense. site_type is a key, not a tag. As a key, it can't be changed to a tag. And changing a tag could be done in the documentation (wiki) and/or in the OSM data and/or in editor templates, these are 3 separate tasks. You need to specify which of those tasks you are taking about. As to your second sentence, you are still ignoring the definition I quoted above. Maybe it's because English is not your native laguage, so you mistake "discardable" (= ready to be discarded in the future) for "discarded" (= has already been discarded)?

When I change the status back, are you going to start an edit war? --Fkv (talk) 13:39, 26 March 2019 (UTC)

To explain again: discardable tags are ones that are silently removed without replacement. Tag site_type=bigstone would not be removed, it would be replaced by site_type=megalith. If there is consensus to do that it means that site_type=bigstone is deprecated (not discardable) Mateusz Konieczny (talk) 07:47, 8 April 2019 (UTC)

I expanded Discardable tags. If you think that either Discardable tags or site_type=bigstone needs to be modified I think that it would be better to discuss it with other members of OSM community. Would it be OK to do it on tagging mailing list? 07:53, 8 April 2019 (UTC)

No need to drag the discussion to yet another place after there has been a discussion on the Talk page for 9 months and nobody (not even the creator of that tag who has been automatically notified of that discussion) objected to even delete the page altogether... --Fkv (talk) 08:21, 8 April 2019 (UTC)

Proposal

What makes you think that because I changed the status to abandoned that it means I have a problem with the proposal and how exactly is changing the status vandalism? The proposal had an RFC in 2015 and has only been edited once since then to add a link to TagInfo. That sounds abandoned to me. There's zero reason for a 5 year old clearly inactive proposal to be considered active, tagged that way, or to be taking up space in the active proposals category. There's no reason it can't just be set to abandoned and then you can update the status later if or when you feel like working on it again. --Adamant1 (talk) 05:54, 18 April 2020 (UTC)

You should read the documentation before fiddling with other people's proposals. It says that "a proposal that's unchanged in the wiki for a while might just be tested in daily mapping practice and thus may be very alive." I had no reason to work on the proposal after the RFC, as it already seems fine enough. I have been using the proposed keys for years, and others use them as well. There are ~14000 instances of addr2:housenumber and addr2:street. If you want to update the status, you should rather set it to "approved", as happened with other proposals such as Proposed_features/farmland. And why didn't you change the status of those proposals that have remained in "RFC" state for more than 10 years, such as Proposed features/information and Relations/Proposed/Site? --Fkv (talk) 08:07, 18 April 2020 (UTC)

I did actually read it. It's not like wondered into the proposals out of know where and just decided to pick on yours. Thanks though. "Proposals should be set to Abandoned if they have a long time of inactivity (at least 3 months) on the wiki pages (including all languages and discussion pages)." That's how it looked to me. If the tags are in wide use and just being used for testing anymore, then IMO that shouldn't have an effect on the status of the proposal anymore. As at that point they are two separate things. Keeping the proposal as active when it's essentially been dead for a number of years give the false impression that it is currently being worked on when it isn't and takes up space in the active proposal category that it shouldn't be. Your free to disagree. Although, really you don't have to be so rude about it. I'm sorry having the word abandoned associated with your proposal hurts your feelings, but that's how it looks to me. And yes of course, I should edit other proposals because no one on here can do anything unless they do everything. Rrrriiiiiiiggghhhtttttt "eye roll." A good solution IMO would be to have an article for the tags with the status in use or de facto and set the proposal to abandoned. Since that's what is technically correct. Despite your clearly hurt feelings about it. --Adamant1 (talk) 08:33, 18 April 2020 (UTC)

I agree that proposals (and proposal status) should be strictly separated from feature pages (and tag status). But that's not common practice. Someone added "in use" etc. to the list of proposal statuses years ago and ignored my objections. It seems that I'm the only one who objected at all. Another problem is that nobody dares to start voting on a controversial proposal, because it might be voted down by people who don't understand it or don't need it themselves. That's why many proposals are left in RFC or even draft state forever. Some proponents bypass the voting by creating an editor template (for JOSM, Id...) that drives mappers into using the new tag and deleting other tags, assuming that the editor and validator conform to standards. Then the proponent waits for the usage numbers to rise, so he can declare the new tag approved and deprecate the old tag. Some don't even create a proposal at all. They just create the feature page and declare it a de-facto. While a proposal in eternal RFC state is not fully satisfactory, it is at least more honest than these sneaky ways to bypass the proposal process.

I think that the "abandoned" status should be used on proposals that are actually abandoned. By that, I mean that the proponent either abandons them himself, or doesn't answer suggestions or questions on that proposal anymore. Same goes for unfinished proposals: I have had a couple of proposals in draft status for ages, but that doesn't mean that I've abandoned them. They are just not yet ready for RFC. --Fkv (talk) 09:53, 18 April 2020 (UTC)

While reading this, it seems there are really more different kind of status available, so i just was editing this page, feel free to change or optimize it. --MalgiK (talk) 18:48, 18 April 2020 (UTC)

Proposal status

You are likely to be interested also in https://wiki.openstreetmap.org/wiki/Template_talk:Proposal_Page#Rename_.22Abandoned.22_to_.22Archived.22 Mateusz Konieczny (talk) 12:09, 12 January 2021 (UTC)

Another attempt

Are all photos listed on https://wiki.openstreetmap.org/w/index.php?title=User:Mateusz_Konieczny/notify_uploaders/Fkv&oldid=2278015

• taken by you
• made available by you on CC BY-SA 2.0 license, like other wiki edits

?

And yes, some people uploaded photos NOT taken by them because they were confused by copyright.

Mateusz Konieczny (talk) 08:59, 7 September 2022 (UTC)

All files that I've uploaded (photos as well as graphics) are my own work unless stated otherwise. I think that's obvious, but I also use to mention it explicitly. If I forgot it somewhere, use the respective talk page or send me an email. Don't damage the wiki pages.

By uploading my files to the wiki, I implicitly grant permission to use them in the wiki. Same as with text. I am not aware of any rule that images must be under a CC-BY(-SA) or PD licence. If I wanted to have my images used in other projects without being asked, I would certainly upload them to Wikimedia Commons instead.

--Fkv (talk) 09:19, 7 September 2022 (UTC)

Your response is a perfect example why I am asking this. See "Content is available under Creative Commons Attribution-ShareAlike 2.0 license unless otherwise noted." in footer. If you have not intended to upload this images on open license then they should be marked as such and deleted/replaced as problematic. Again: please specify exact license under which you think you uploaded this images or you are willing to license them. Once it is clarified next step can be determined. Right now it appears that you want license so restrictive that it will be necessary to replace and delete them. Can you confirm that you intended something along lines "it can be used only in OSM Wiki and nowhere else" and you are not willing to use more open license? Mateusz Konieczny (talk) 10:59, 7 September 2022 (UTC)

Well, that's strange. In the file upload dialog, there is no such footer. But on the file view page, there is. Looks like a bug in the Wiki system.

If files need a licence, the licence listbox in the file upload dialog should not contain a "none selected" option.

If for whatever reason the files are CC-BY-SA 2.0 by default, then I'm ok with that. But still, the upload dialog needs to be fixed. You can't let people upload files and then complain about the licence. This check needs to be performed at upload time. --Fkv (talk) 11:44, 7 September 2022 (UTC)

"If files need a licence, the licence listbox in the file upload dialog should not contain a "none selected" option." - that actually makes some sort of sense. This way people completely confused will not assign fake licenses for files they got from image search and it is easier to spot this. But yes, overall files and upload interface were basically not maintained for a long time, and it is a complete mess. I am trying to cleanup it at least partially but as demonstrated in our discussion this is quite hard to do properly, and there is a really large backlog (at start: more than 30 000 images, now about 24 000). Mateusz Konieczny (talk) 12:02, 7 September 2022 (UTC)

Mandatory selections without preselected items work like this: <select required><option value="">none selected</option><option value="1"...

You can't ask the authors of all the 30000 images for a licence, because a significant fraction of the authors have already died. The OSM wiki has been online since 15 years at least. Also, not everyone has time to answer your questions. Deleting work by other people without their permission is the worst possible violation of copyright laws. Copyright works the other way round: If a file is used without a proper licence, it's up to the author (or other rightholder) to request a deletion of the file. --Fkv (talk) 12:43, 7 September 2022 (UTC)

"Deleting work by other people without their permission is the worst possible violation of copyright laws" - it may be a bad idea (or not), but it is definitely not a violation of any copyright law Mateusz Konieczny (talk) 12:50, 7 September 2022 (UTC)

In my country's (Austria) law, it's in UrhG § 21 Abs. 1, and UrhG § 89b Abs. 1. I don't know about British law though. --Fkv (talk) 14:12, 7 September 2022 (UTC)

As far as I can see these are exceptions for specific law: not ban on all deletion for copyright related reasons (so deletion is not mandatory, which does not make it forbidden). But I am not a lawyer and relied on Google-translate. But in general noone is obligated to store files just because they are openly licensed or claimed to be openly licensed or suspected to be openly licensed. Mateusz Konieczny (talk) 15:06, 7 September 2022 (UTC)

Same namespace for different types of (natural) crater

Hi, any thoughts regarding the "natural" namespace (vs. "historic" / "geological") ? Rtfm (talk) 13:58, 11 January 2023 (UTC)

Landforms are usually tagged with the natural=* rather than the geological=* key. I haven't mapped many natural craters (apart from natural=sinkhole, which we don't call craters), because few volcanos or meteorite impact craters exist in my country.

Bomb craters are not natural. They are tagged with historic=bomb_crater exclusively. I think it's me who invented that tag (as well as natural=sinkhole), but it's now in widespread use.

Of course, not all bomb craters are "historic" in the sense of a creation in a distant past. Wars are still going on, and explosions happen for other reasons as well. But those recent craters are either flattened soon, or they soon become relicts of past events. They don't remain active in any way. In that sense, they are always historic. That justifies the exclusive use of the historic=* key, even more so than historic=wayside_shrine and wayside_cross on brandnew shrines and crosses. --Fkv (talk) 15:15, 11 January 2023 (UTC)

That's why I added the "see also" section, might be interesting whether a street is usable or not (for HOT topics). At least the namespaces should be harmonized. The discussion about natural=crater (especially what it's used for and how to distinguish differences) died in 2015... Rtfm (talk) 15:23, 11 January 2023 (UTC)

The entire military=bombcrater page should be deleted because the standard tag for bomb craters is historic=bomb_crater. Whoever wants another tag, should write a proposal and not mislead new mappers with wiki pages for wrong tags.

When a street is not usable, you can either map a barrier=* (I've used barrier=pit a few times), or remove the destroyed road section in OSM (or leave the section as a way but remove the highway=* tag). --Fkv (talk) 20:48, 11 January 2023 (UTC)

I stumbled on this undocumented (but used) tag and documented it. When I have a look at the crater discussion there wasn't anything going on since 2015. So this is the "proposal" I'm doing right now (unbureaucratic, "on the fly") : see link above. Contacted several which had to do with it in the last decade. Let's see.Rtfm (talk) 21:52, 11 January 2023 (UTC)

No, it's not a used tag. It has around 100 instances, while historic=bomb_crater has around 10000. And no, that's not how the proposal process works, and I don't see any reason to propose a synonym to an already existing tag. You just mess things up.

Not sure which discussion you are talking about, but there may be a reason why nobody felt a need to continue that discussion. If you do feel a need, do it. But use the "Diskussion" tab (also known as Talk page) for that, not the feature pages. --Fkv (talk) 22:11, 11 January 2023 (UTC)