User talk:Geozeisig

From OpenStreetMap Wiki
Jump to navigation Jump to search

Filing cabinet icon.svg Archiv

Standard tile layer legend


Thanks for updating cemeteries on Standard_tile_layer/Key, but there are still some old renderings which have less dense patterns now (I mean File:Landuse cemetery jewish.png and File:Landuse cemetery christian.png). Do you plan to update them too?

It would be also great if somebody continue to update this page, since I try to concentrate on osm-carto development and lack the time to do everything I could even there. Could you take care of this? --Kocio (talk) 13:50, 5 March 2018 (UTC)

I can take care of it. Of course only as time permits. But hints if something has changed are very welcome.
Can it somehow be used as a legend in carto?--geozeisig (talk) 16:39, 5 March 2018 (UTC)
Great! That's why I plan to at least keep adding TODOs with links to the changelogs.
I'm not sure what's the best solution with such unusually big legend, but I hope we can find it. I invite you to take part in a discussion in osm-carto repo. --Kocio (talk) 17:24, 5 March 2018 (UTC)
The examples of area are different sizes, many 125 x 125 some 100 x 100. Should they not be the same? Which size would be nice? For areas that have only one color you can also resize later, but if they contain a pattern it is not so obtimal.--geozeisig (talk) 07:57, 7 March 2018 (UTC)
There's just a few of 100x100, so it might be easier to replace them, on the other hand smaller tiles would make the legend shorter, which would be more comfortable for users (less scrolling), so smaller tiles would be better solution to me, however more tedious. --Kocio (talk) 12:03, 7 March 2018 (UTC)
On the website Key:landuse the rendering is 100x100 where the images are reduced from 125x125. So pictures in size 100 would also be an advantage here. But for a legend, even smaller pictures would be good. What would you suggest? --geozeisig (talk) 13:15, 7 March 2018 (UTC)
I forgot about scaling images in HTML! That would make it much easier. I don't know what size is good, so just do as you think would be the best. You might even make a template for showing these tiles, so you would set the size only in the template by default and all the pictures would have the same size, which could be changed just by changing the template (- I hope I speak clear enough). --Kocio (talk) 13:41, 7 March 2018 (UTC)
Then I would prefer 125x125. There are only a few. I would re-upload the svg file.--geozeisig (talk) 13:51, 7 March 2018 (UTC)
There is entrance=yes Rect.svg and entrance = main Entrance main.svg. Where should that be arranged?--geozeisig (talk) 08:37, 7 March 2018 (UTC)
There are also some other renderings of entrances, also combined with access (see the test here), so I guess you can just add another section in symbols ("Entrances"). --Kocio (talk) 12:03, 7 March 2018 (UTC)
I would like to divide the page. Maybe in the topics points, ways and areas. Maybe tabs would be useful as they are used on Wiki. I just do not know how it's done. ((:Wiki/Tabs)) is the only thing I found (I had to replace the chambers).--geozeisig (talk) 13:47, 7 March 2018 (UTC)

I've made some fixes for shoal, beach and sand in Standard_tile_layer/Key#Areas. It's a bit convulted ("Generic beach or shoal" uses image withe the name sand and "Sand, beach or shoal with sand surface" uses the image with beach in the name), but that's how does it look like now. We should fix the renderings on the definitions for all these tags. --Kocio (talk) 14:06, 7 March 2018 (UTC)

Revision 1596199 on power=tower

Hi, could you please give details on why the revision 1596199 on power=towerhas been undone please?
I thought it was ok as tower designs have to go on design=*. They are now redundant between power=tower and design=*. All the best Fanfouer (talk) 08:09, 6 April 2018 (UTC)

The revision has been done be Gazer75. I would also like to know why he has reverted it.--geozeisig (talk) 10:32, 6 April 2018 (UTC)
Oups, sorry :) i'll post the same question on its wall Fanfouer (talk) 10:41, 6 April 2018 (UTC)
Sorry guys, I didn't fully understand the reason for the change at the time. A big page edit could at least had a note in summary why it was changed. I had no idea all the design examples had gotten its own page now. It was also strange that the tower:type= is now said to be bad tagging for power towers. This has to be a mistake. We need to be able to use that key to tell if a tower is a branch and so on. The values for for this one on towers will not be the same as for com tower types anyway. Gazer75 (talk) 14:50, 7 April 2018 (UTC)
Please, explain why you are doing edit if it deletes large part of the page, "update" is not only useless - it is misleading Mateusz Konieczny (talk) 14:01, 8 April 2018 (UTC)
The page design=* and tower:type=* contains the information. The information should not redudantly stand in two places. There have been other improvements that you can not list individually. So I marked it with update.--geozeisig (talk) 05:53, 9 April 2018 (UTC)
In that case it would be preferable to make content removal edit with "removing content duplicated from design=* and tower:type=*" and minor updates in a separate edits - so it would not look like a mistake Mateusz Konieczny (talk) 10:57, 9 April 2018 (UTC)

Please, stop removing descriptions

Describing amenity=bank as "bank" is useless. Description "A financial establishment where customers can, among other services, deposit money and take loans." is more helpful.

In the same way describing tourism=picnic_site as "picnic site" is useless - please avoid edits like or

On topic of adding public requirement - is it discussed anywhere? I am pretty sure that it was not discussed recently on tagging mailing list Mateusz Konieczny (talk) 08:52, 14 May 2018 (UTC)

> Came here to say the same thing regarding, the description should be more than just the name. I've tagged a few of private fitness_stations leisure=fitness_station + access=private, so don't agree it should be public only. Aharvey (talk) 10:32, 14 May 2018 (UTC)

If you're looking for a picnic site on a map with POI and you get a private place that's confusing.
The description in the infobox should be short, a longer is in upper part on the main page.
Describing amenity=bank as "bank" is useless. That's just for the English language. For everyone else, the description is the translation of der value. And the English side is the role model. Therefore, on the English side should also have a short description.--geozeisig (talk) 13:17, 14 May 2018 (UTC)
"bank" is not a description, even a short one - it is just a label. And unnecessary one given that tag is "amenity=bank". "For everyone else, the description is the translation of der value." - I am not understanding this, can you rephrase? Mateusz Konieczny (talk) 08:03, 16 May 2018 (UTC)
See also - the suggestion that had been made there was to add a new label field to the template to cater Geozeisig's desire to have a simple label for every tag and to leave the description field for what it is intended for - namely to describe the tag in question shortly without being self referential.
This this will probably not happen before Geozeisig has dumbed down the description of every tag page in existence i wonder if there is a way to then rename the template field from description to label and after that automatically restore whatever value description had before he made the first edit to it. ;-)
--Imagico (talk) 21:47, 14 May 2018 (UTC)
@Imagico Agree a label field makes perfect sense, description should remain as is. @Geozeisig The issue also with changing description to public only is as far as I can tell that was never discussed. I feel it's mapping for the application. If tagged access=private the application can choose to either hide it or show it but as private.
"before Geozeisig has dumbed down the description of every tag page in existence" - well, I keep reverting him at least on English pages. If he/she continues after this discussion I will try something more effective Mateusz Konieczny (talk) 08:03, 16 May 2018 (UTC)
"add a new label field to the template to cater Geozeisig's desire" - I would not oppose this, but I see no value in it. If Geozeisig really wants it he/she may either add it to template or find somebody able and interested in adding this new parameter Mateusz Konieczny (talk) 08:05, 16 May 2018 (UTC) After additional info from Imagico (below) I am against it as it would encourage further damaging edits Mateusz Konieczny (talk) 13:44, 16 May 2018 (UTC)
It would be nice if that new field rendered within div/p html object with specific id so it can be easily hidden with an adblock Mateusz Konieczny (talk) 10:59, 16 May 2018 (UTC)
Well - Geozeisig has expressed the understandable desire to translate the tags into different languages. This is somewhat misguided because (a) there typically is no such thing as a 1:1 translation of terms into different languages and (b) tags do not generally mean exactly what their values mean even in English. I explained this in more detail in the previous discussion in German. To give an example - man_made=embankment in German has the description Böschung, Abhang - this is misleading because these terms in German do not imply an artificial structure while the tag in OSM does (the English description is not accurate either but that is a different story). So for properly learning what a tag means - even just in broad strokes - you need more than a single word and allowing that is exactly the purpose of the short description in the template.--Imagico (talk) 12:40, 16 May 2018 (UTC)
In that case I am against adding label field as it encourages invalid edits. Geozeisig, please stop this kind of editing - it is better to gave proper description than a single word that is misleading or is not explaining situation properly Mateusz Konieczny (talk) 13:44, 16 May 2018 (UTC)
I'm sorry, this discussion in English is difficult for me.@Imagico I see that a description is often not accurate enough with just one word. But it should be short and definitely include the word (value).--geozeisig (talk) 13:58, 16 May 2018 (UTC)
I don't think this is a good requirement, this leads to awkward descriptions (Of the type A foo is a ...), in particular in case the meaning of the tag conflicts with some meanings of the English language term matching the value (like leisure=park) leading to people attempting to fix it because they view it as a false statement. In languages other than English this is not a problem - you can describe the tag with any terms suitable - but in English this is not a good idea. It benefits mapping quality if you eliminate the middle man here - instead of man_made=embankment is an embankment which is a <description in other words> go strait to man_made=embankment is a <description in other words>. An established tag always detaches itself from the original meaning of the English language term used for the value to some extent over time.--Imagico (talk) 14:44, 16 May 2018 (UTC)
To me, "a financial establishment ..." feels like an attempt to define the meaning of "bank", when the goal should instead be to define the meaning of "amenity=bank". A longer description only makes practical sense if the meaning of the tag is different from that of the English word, which may of course be the case. But where there is no such difference in meaning, it makes no sense trying to paraphrase. --Tordanik 15:23, 16 May 2018 (UTC)
In languages words have not always a universal meaning, in particular in English which is spoken across very different cultures. So relying on a certain subjective interpretation of a single word is not a very good idea, even if you think this interpretation has universal validity. I explained this in the previous discussion with the term reef and that its meaning is not something you can build on. This is why a description is useful. It puts the meaning of the abstract concept behind a tag into a broader verbal context. --Imagico (talk) 15:37, 16 May 2018 (UTC)
If this is actually a problem with a particular definition, then sure, point that out. But what I'm trying to say is that ...
  • there's nothing wrong per se with using a one-word definition, as long as it's still correct and unambiguous.
  • a word appearing in the tag itself is not an argument against using it in the definition.
--Tordanik 16:36, 16 May 2018 (UTC)
"there's nothing wrong per se with using a one-word definition, as long as it's still correct and unambiguous." I agree in principle, though I am unable to give any example of any case where it would be sufficient Mateusz Konieczny (talk) 16:44, 16 May 2018 (UTC)
A description does not have to be a definition, it is meant to describe the meaning of a tag without depending on a certain interpretation of the meaning of specific terms by providing a broader verbal context. Often this is done by explaining the function a certain feature has or the way it relates to other objects.
As far as definitions are concerned (which as said is not really the issue here), yes, there is nothing wrong per se with using a one-word definition - but the problem is the author of a definition is universally not able to assess if the reader of the definition has the same understanding of this one word. Therefore a reliable definition likewise uses indirect methods to define things (for example by listing functional requirements to comply with the definition or exclusion criteria - like the famous stream-river distinction). --Imagico (talk) 17:07, 16 May 2018 (UTC)

bay=fjord on relations

Hi, I saw you set bay=fjord on relation to "no" and I was wondering the rationale for this? Surely this must be a valid way? A majority of the uses now are on relations FredrikLindseth (talk) 10:34, 17 November 2018 (UTC)

Please read multipolygon is a relation. If the tag is used in the mulipolygon, that does not count as a relation tag.--geozeisig (talk) 15:01, 17 November 2018 (UTC)
Then what does?? The talk you link to did not help at all. The tag is used in a relation and thus should be flagged as able to be part of a relation tag.
Anything else is just making the wiki confusing. Looking at the Elements page it clearly list multipolygons. Gazer75 (talk) 15:19, 30 November 2018 (UTC)

Tagging for renderer is bad

Please read

Tagging for renderer is undesirable, please do not promote it like you did in (leisure=track is for nonmotorized racing only) Mateusz Konieczny (talk) 14:52, 25 January 2019 (UTC)

Redirecting translated pages


bzgl. der Weiterleitung von type=side möchte ich sagen, dass ich es immer am besten finde, wenn alle Übersetzungen konsequent auf eine andere Seite weitergeleitet werden. Andersherum finde ich es verwirrend, denn wenn man die russische Version liest und dann zur englischen und zurück wechselt, kommt man auf eine andere Seite und wundert sich. Ich habe dann jetzt die russische Seite auch weitergeleitet. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 17:26, 8 May 2019 (UTC)

Tag:type=site ist ein Fehler es muss Relation:site heißen. --geozeisig (talk) 05:38, 9 May 2019 (UTC)
Nachricht richtig verstanden? Darum ging es in meiner Nachricht nicht. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:38, 10 May 2019 (UTC)

Entfernung einer Weiterleitung

Was war der Grund für diese Bearbeitung an der Seite Template:De:Map Features:man made? Dadurch gibt es wieder zwei Vorlagen, einmal mit De und einmal mit DE, die fast gleich sind (Unterschied). Das ist mMn kontraproduktiv, weil die Änderungen nicht automatisch auf alle Seiten übertragen werden können. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 09:33, 10 June 2019 (UTC)

Man baucht eine Umleitungsseite weniger. Du dast recht die DE -Seite könnte gelöscht werden.--geozeisig (talk) 08:20, 11 June 2019 (UTC)

Edit description

Please, do not describe your edit as "syntax" if it is changing also content - see that also reverted some of my edits. If you think that edit should be reverted - it is OK to do this, but please do not use misleading descriptions. Mateusz Konieczny (talk) 13:54, 11 June 2019 (UTC)

I got a mail and looked for the changes. I saw a small mistake that could be fixed quickly ("Note that in many cases Template:Military objects are mapped separately,...")
I had not noticed that you have already corrected the error later. Sorry for that. --geozeisig (talk) 05:52, 12 June 2019 (UTC)

geozeisig, thank you for updating Tag:tourism=picnic_site from "in use" to "de facto" status. However, could you please describe the edit more fully? Rather than writing "status", you can put "status de facto" or better "changed status from in use to de facto because..." --Jeisenbe (talk) 13:03, 30 August 2019 (UTC)

OSM Wiki is not a dictionary

Can you fix Tag:plant:method=gasification? It should describe OSM tag, not word "fermentation". Mateusz Konieczny (talk) 09:16, 31 August 2019 (UTC)

Can you do it please. I copied the text from generator:method=gasification.--geozeisig (talk) 09:27, 31 August 2019 (UTC)

New Key:aerodrome proposal

See Proposed_features/Key:aerodrome - thank you for your help in discussing this. Please add any comments or improvements you can think of. --Jeisenbe (talk) 07:49, 10 September 2019 (UTC)

Thanks for the link. I was on vacation and offline. Now a lot has stopped and I have to get used to it again. Greeting --geozeisig (talk) 10:07, 16 September 2019 (UTC)

historic=aircraft tagging

Hi, regarding your recent change ( to the aircraft tagging scheme: The scheme was suggested by me and added to the wiki by a German user because of my inadequate command of German. Do we need general aviation _and_ airliner? Yes, a Cessna 172 is a general aviation aircraft whereas a Boeing 737 is an airliner. GA aircraft are typically privately operated and used for private transport, or privately hired (what was once known as "aerotaxi"). Airliners are typically operated by airline companies and used for mass passanger transport. A GA aircraft is to an airliner what a passenger car is to a bus.

Also, why do you suggest that aircraft:type be used instead of aircraft:role? Where should the type go then? (I suspect this has to do with the English "type" and German "Typ" denoting different things.) You're suggesting different values under aircrat:type that actually belong to orthogonal categories: is an F-14 an aircraft:military or an aircraft:jet? Is an Mi-8 an aircraft:helicopter, aircraft:transport, or aircraft:military? Regards, Michalfabik (talk) 09:35, 21 January 2020 (UTC)

Eine oder vier Routen auf dem Bild

Mit den vier Routeneinschüben werden vier Fahrradrouten ausgeschildert.


du hattest gestern mit deiner Änderung an DE:Tag:route=bicycle meine Änderung zum Bild rückgängig gemacht.

ich: "Vier ausgeschilderte Fahrradrouten"

du: "Ausgeschilderte Fahrradroute"

Was waren deine Beweggründe?

Meines Erachtens ist das so nicht mehr richtig. Auf dem Bild sind 4 Fahrradrouten ausgeschildert:

  1. Die D4-Route
  2. Thüringer Städtekette
  3. Ilmtal-Radweg
  4. Feininger Route

Ich habe die Zahl genannt, damit klar wird, dass die Routen erst durch die Symboleinschübe ausgeschildert werden. Auf die Zahl "vier" kann ich ja noch verzichten, wenn es dafür einen guten Grund gibt. Die Einzahl "Fahrradroute" ist m. E. jedoch nicht korrekt.

Viele Grüße,
Jochen --Jo (talk) 21:39, 30 March 2020 (UTC)

Bei description soll eine kurze Beschreibung des Tags gemacht werden, keine Beschreibung des Beispielbildes darüber. Der Text könnte auch lauten Weist Releation als Fahrradroute aus. --geozeisig (talk) 06:26, 31 March 2020 (UTC)
Ah, da hast du Recht, Danke! --Jo (talk) 19:04, 31 March 2020 (UTC)

parking=street_side im deutschen Wiki

Hey, auch wenn du parking=street_side nicht magst und dagegen gestimmt hast, wurde das Proposal mit großer Mehrheit (23:2) angenommen, daher gehört der Value auch in die entsprechende Liste. Du hast die Änderung jedoch rückgängig gemacht. Warum? --Supaplex030 (talk) 08:37, 30 November 2020 (UTC)

Autoparkstreifen entlang von Straßen werden mit parking:lane=* kartiert. Wenn ihr daraus echte Parklätze macht, ist das nicht mehr in der Definition von amenity=parking.--geozeisig (talk) 15:58, 30 November 2020 (UTC)
Ja, ich weiß dass du da eine strenge Auffassung pflegst. Nur hat das Proposal-Voting gezeigt, dass 87 Prozent der Teilnehmenden da durchaus Spielräume sehen. Du verhinderst damit nicht, dass Mapper Parkbuchten separat mappen, sondern höchstens, dass sie als solche erkennbar sind. (Eine Parkbucht ist außerdem etwas anderes als ein Parkstreifen). Bitte füge den Value wieder ein oder lösche es wenigstens beim nächsten mal nicht wieder oder mache einen Vorschlag für eine angemessene Beschreibung dieses Values, wenn diese dich stört?
Ein paar fix zusammengewürfelte Beispiele aus Berlin, um zu verdeutlichen worum es geht:
  • Sollte man diesen Parkplatz etwa nicht mappen, wenn er 10 Meter weiter südlich am Straßenrand wäre? Oder fändest du einen parking:lane-Schnitt hier etwa angemessen?
  • Fälle wie diese gibt es zu hunderten, wenn nicht tausenden allein in Berlin, seit Jahren. Warum sollten diese durch das neue Tagging nicht klar von "richtigen" Parkplätzen unterscheidbar sein? Insbesondere auf Mittelstreifen ist es im Übrigen sehr weit verbreitet und akzeptiert, Parkplätze separat zu mappen. Oder willst du etwa jedem einzelnen dieser Parkplätze hinterherlaufen und sie wieder löschen?
  • Würdest du kleinere Parkbuchten wie diese einfach nicht erfassen oder etwa auch für einen parking:lane-Schnitt plädieren?
Mit Beispielen von Orten mit hohem Micromapping-Anteil (und der Frage, ob du dort gern "schwarze Löcher" hättest) fange ich gar nicht erst an. --Supaplex030 (talk) 16:56, 30 November 2020 (UTC)
P.S.: Falls es dir tatsächlich nur um den Spam blauer P-Symbole geht, solltest du dir am besten nicht die vorbildlich gemappten Fahrradabstellanlagen in Neukölln anschauen ;) --Supaplex030 (talk) 17:06, 30 November 2020 (UTC)
Der Parkplatz in der Septimerstraße hat jedenfalls eine Zufahrt und ist als Platz zu erkennen. In der Arnold-Zweig-Straße wird parallel geparkt, es gibt aber auch keine Zufahrt oder Platz, es müsste eigentlich mit parking:lane:left=parallel getaggt werden. In der Berliner Str wurde amenity=parking_space benutzt, eine Möglichkeit die ein guter Kompromiss ist.
Aus der Wiki amenity=parking: Diese sollten eine gewisse Größe aufweisen, es soll also nicht für jede kleine Möglichkeit ein Auto abzustellen ein Parkplatz eingetragen werden. Man kann das doch nicht einfach umdeuten. --geozeisig (talk) 08:00, 1 December 2020 (UTC)
Im englischen Wiki gibt es vernünftigerweise keine Einschränkung dieser Art ~ warum auch: Map what is on the ground. Ich wiederhole noch einmal einen Absatz aus einer meiner früheren Nachrichten: "Ja, insbesondere das deutsche OSM-Wiki hat da ein sehr enges Verständnis von einem “Parkplatz”, aber OSM ist ja zum Glück kein statisches Gebilde. Die Formulierung “Diese sollten eine gewisse Größe aufweisen, es soll also nicht für jede kleine Möglichkeit ein Auto abzustellen ein Parkplatz eingetragen werden.” stammt beispielsweise aus den ersten Tagen dieser Wikiseite und ist 12 Jahre alt. Ich bezweifle, dass sie mit den gewachsenen Ansprüchen an OSM noch kompatibel ist - ganz zu schweigen von der Mapping-Realität."
amenity=parking_space ist eine Ergänzung auf ausgewiesenen Parkflächen mit amenity=parking, um einzelne markierte Parkplätze für einzelne Fahrzeuge zu mappen, wäre alleinstehend für diese Zwecke also falsch. amenity=parking + parking=street_side ist für diese Zwecke geschaffen und wochenlang diskutiert worden: Also wenn Mapper Gründe sehen, diese Flächen separat zu mappen, dann so. Wir drehen uns im Kreis – wie kommen wir da wieder raus? --Supaplex030 (talk) 08:50, 1 December 2020 (UTC)
Du hast recht wir drehen uns im Kreis und da weiß ich auch nicht wie eine Gute Lösung aussieht. Vielleicht kann ein Außenstehender etwas beitragen, aber das Forum scheint für mich keine Lösung zu sein. Da fehlt es am guten Ton. Ich bin schon froh, wenn du auch meine Ansicht verstehst und dir auch auffällt das da in Neukölln vorbildlich gemappten Fahrradabstellanlagen in Neukölln vielleicht etwas zu sehr ins Auge stechen.--geozeisig (talk) 08:15, 2 December 2020 (UTC)
Vielleicht auf der DE: oder Berliner Mailingliste ansprechen für Drittmeinungen? --Supaplex030 (talk) 12:56, 2 December 2020 (UTC)

Am 11. Dezember 2020 haben wir Online-Stammtisch, mögt ihr da dazu kommen?--Polarbear w (talk) 10:46, 3 December 2020 (UTC)

Ich werde dabei sein. Lg, --Supaplex030 (talk) 11:09, 3 December 2020 (UTC)

healthcare:speciality=vaccination - why "rejected"?

Hi, I just reverted your edit to the page healthcare:speciality=vaccination. You marked the tag as "Rejected", to be replaced with "healthcare=vaccination_centre" instead. However, on that very page it is explained that these two tags serve different purposes, and may even be combined.

Maybe we should update the page to better explain the difference between the tags? Could you explain what was unclear? I also started a discussion on the talk page of healthcare:speciality=vaccination about the tag - feel free to join! Sleske (talk) 10:14, 21 January 2021 (UTC)

Maybe I didn't understand something right there. According to what is in the proposal, you should only use healthcare=vaccination_centre for a vaccination center. For me it is clear.--geozeisig (talk) 16:29, 21 January 2021 (UTC)
There was nothing in the healthcare=vaccination_centre proposal saying it would be the 'only' primary key, and it did not vote about healthcare:speciality=vaccination, in particular it did not 'reject' anything. It also did not deprecate the usage of any other primary key, see that in Germany using healthcare=centre is more popular. --Polarbear w (talk) 18:13, 21 January 2021 (UTC)

cycleway:both = lane is rendered

See (re ) Mateusz Konieczny (talk) 08:17, 22 January 2021 (UTC)

I looked at the other cyclist map (layer C at But thanks for looking.--geozeisig (talk) 07:07, 23 January 2021 (UTC)

See also

Note that due to data items intrusion, you will need to edit also to remove that from infobox (and after you modify data item you will need to make a null edit).

But, anyway, I would reconsider removing it from - railway=preserved is still widely used, mentioning it in see also seems correct to me Mateusz Konieczny (talk) 11:09, 10 April 2021 (UTC)