Talk:Wiki/Archive 12

From OpenStreetMap Wiki
Jump to navigation Jump to search
Protection
 This page includes archived discussions. Please use Talk:Wiki to start a new discussion.

Redirects from prefixless forms to Key: and Tag: articles

Resolved: No changes decided upon. --Chris2map (talk) 16:23, 3 November 2025 (UTC)

Whenever I search for a combination such as foo=bar I get slightly irked by being presented with search results, rather than immediately redirected to Tag:foo=bar. We do have a few such redirects in place, such as ref→Key:ref, but those have been created haphasardly, since, for example, int_ref is currently a redlink rather than a redirect to Key:int_ref.

Having such redirects in place would also be beneficial for linking from e.g. the Community Forum to Wiki pages -- since it's commonly used, it may be even assigned a custom Markdown syntax if there's enough interest.

Now, there are thousands of pages with Key: and Tag: prefixes, and only a few redirects in place. If we decide having such redirects would be a good idea, Someone(TM) would have to develop a script or bot to create (and/or maintain) them. Duja (talk) 13:33, 28 February 2024 (UTC)

If you need such a redirect for some frequently used tag, then just create it. I do that sometimes. I usually start by typing in some popular word, such as restaurant or restauracja. If there is no such redirect, I create it. There is no objection to creating such redirects, but I don't see the point in automating this and creating them for all tags, e.g. diplomatic:services:non-immigrant_visas, which will redirect to Key:diplomatic:services:non-immigrant_visas. maro21 19:54, 28 February 2024 (UTC)
I'm not shy on editing Wiki (coming from the Wikipedia world), and I also created a few such redirects. As I said, I'm only slightly irked, but as we know, irk tends to accumulate over time, so I wish we would automate the process. I suppose that irk fades in comparison with encountering admin boundaries glued to roads glued to landuse glued to waterways, with a dose of multipolygon relations to ensure everything stays glued and can never be edited... Duja (talk) 21:06, 28 February 2024 (UTC)

Equivalent of {{Tag}}, but links to data items

Resolved: templates has been created Something B (talk) 09:16, 5 November 2025 (UTC)

Usage:

For example, shop=clothes. Something B (talk) 13:12, 14 March 2024 (UTC)
Thanks for the info. Documentation for the template would be useful. And maybe a different background color to distinguish these links from the regular ones. maro21 22:43, 14 March 2024 (UTC)
I also had a similar question when I wanted to add a general link to data item to the tag description boxes (Template:Data item link). Unfortunately we don't have an icon for data items, like with taginfo. Perhaps one of the following display variants can be used instead:
  1. variant for link to #shop=clothes
  2. variant for link to d.i.shop=clothes
  3. variant for link to dishop=clothes
  4. variant for link to ‹›shop=clothes
  5. variant for link to ■shop=clothes
  6. variant for link to shop=clothes
  7. variant for link to d.i.shop=clothes
--Chris2map (talk) 11:57, 17 March 2024 (UTC)
There are some emojis that can be used as icons for data items. Here are several I selected from this query on emoji DB:
  1. 📊
  2. 📋
  3. 📝
  4. 🧾
  5. ✉
  6. 🛢
I like #2 ("Clipboard" emoji) best, e.g. 📋shop=clothes. Duja (talk) 09:02, 18 March 2024 (UTC)
Note that we already have {{O}} for linking to data items, which is quite flexible in the output formatting. In any case, even if we keep Something B's templates around, they can be reduced to a single template called e.g. {{Item}} rather than having three quite similar copies. Duja (talk) 09:39, 18 March 2024 (UTC)
This templates uses Special:ItemByTitle in comparison to {{O}} which uses item ID. {{ValueItem}} and {{TagItem}} are analogous to {{TagValue}} and {{Tag}}, respectively. {{KeyItem}} may be replaced with {{TagItem}}, if someone add branches, as in {{Tag}}. Something B (talk) 10:04, 18 March 2024 (UTC)

Syntax for relation role page names

Resolved: Property:P54 had been created. --Chris2map (talk) 16:30, 3 November 2025 (UTC)

Hi, there's been some discussion at ideditor/schema-builder#174 GitHub about creating a wiki page for each relation role, to make it easier for editors like iD to access the documentation for a specific relation role.

There is a question about what the syntax should be for the page names. For example:

Does anyone have suggestions or ideas? There's some more info and context in the github issue. thanks! --Kylenz 20:10, 30 December 2024 (UTC)

I don't think we need separate pages for roles. There isn't much information to create a new article. Roles should be described on relation pages. maro21 21:56, 30 December 2024 (UTC)
I agree with maro21 that roles are best described on relation pages. A few pages about roles do exist, such as Role:from or Role:outer, but they act more like disambiguation pages. However, what we should do is to improve descriptions on data items, which are displayed in iD's user interface (as tooltips?). For example, Item:Q16069 currently has empty English Description field.
As Minh mentioned on Github, all role data items are listed at Special:WhatLinksHere/Item:Q4667. Duja (talk) 09:59, 31 December 2024 (UTC)
I added descriptions for two dozen most common roles [1]. Duja (talk) 12:18, 31 December 2024 (UTC)
As long as we consider the relation article to be the source of truth regarding the roles, the relation type's item needs to indicate the associated roles somehow too. I've created relation member roles (P54) to link from the relation type item to each of the role items for that relation type. From a computer science standpoint, such an inverse property would be frowned upon, but here it's just a consequence of our content organization. This isn't quite a solution for gaining access to the role descriptions, but it gets us a little closer. – Minh Nguyễn 💬 09:07, 5 January 2025 (UTC)
Aren't those just the inverse relations of belongs to relation type (P43), and could be obtained by querying those (not that I'm familiar with the API)? I'm fairly wary of including fully redundant information in the data model. Duja (talk) 19:06, 5 January 2025 (UTC)
@Duja: Yes, it is an inverse relationship. The basic Wikibase API offers no built-in way to query inverse relationships. Special:WhatLinksHere isn’t quite the same because it doesn’t care at all about the semantic context, just the link in the rendered output. We’ve been waiting for WikibaseCirrusSearch, but even this isn’t quite adequate; it’s more for search than for parsing deterministically. Sophox would be the prime tool for more flexible queries on this Wikibase instance, but it isn’t in a state of health that we could confidently point popular editing software to its live API. My point of reference is Wikidata, which generally frowns upon inverse properties but sometimes makes an exception for properties such as has subsidiary (P355). Compared to the bogus sitelinks, this might be the lesser of two evils. – Minh Nguyễn 💬 05:50, 6 January 2025 (UTC)
Annnnd I just realized Data items#Relation roles documents that each role item already has a sitelink to a bogus nonexistent article such as "Relation:boundary=admin centre". So this already makes it possible to query for the role item without creating any pages. The only downside is that the documented syntax is very well-hidden and could have some unexpected side effects based on what the user enters as the role in iD. – Minh Nguyễn 💬 09:31, 5 January 2025 (UTC)

Organizer keeps removing reference from own activity on the Organised_Editing/Activities

Resolved: at least for the discussion here. --Chris2map (talk) 17:24, 3 November 2025 (UTC)

Admins, please give a look at recent edits on https://wiki.openstreetmap.org/w/index.php?title=Organised_Editing/Activities&action=history . An individual of one of the 3 organizations involved is removing any reference of own activity from the list. I'm unsure if something similar happened in the past, but how to react to this?

(by the way: the armchair organized editing happened in my province, and I can plan a trip to survey it.) --EmericusPetro (talk) 07:29, 21 December 2023 (UTC)

I commented in https://wiki.openstreetmap.org/wiki/User_talk:Everton_Bortolini - but maybe you know, is it duplicate of documentation existing already? If yes, where it exists? Mateusz Konieczny (talk) 14:00, 21 December 2023 (UTC)
@Everton Bortolini: Mateusz Konieczny (talk) 14:01, 21 December 2023 (UTC)
I think it would make sense to have detailed problem list in 2023 Brazil Floods where there is more space for them, with only summary in Organised_Editing/Activities. Not sure should it get own entry or be noted in HOT entry (is it HOT-run edit?). From looking at scale of issues it may make sense to let know more HOT people about the problem (if you have time, interest etc to join their forum/slack/whatever) - or just let them know using info@hotosm.org provided at Organised Editing/Activities/Humanitarian OpenStreetMap Team (in either case noting whether they responded also makes sense) Mateusz Konieczny (talk) 18:28, 21 December 2023 (UTC)
@Mateusz Konieczny: I agree to move the community objections another and just leave a summary on Organised_Editing/Activities. However, the copy needs to be in a dedicated page, where it cannot be simply edited at will by the other side like what is happening right now. And the organizers lied while defending it could be deleted from the listing: on https://wiki.openstreetmap.org/w/index.php?title=Organised_Editing/Activities&oldid=2633081 the change summary of changes uses "(...) Notes were copied to the project wiki page." without faithfully copying what was written on the target page. If anyone wants an example omissions/changes, I can detail better, but it was not copied. If the activity organizers will challenge if what's written is not local community opinion, their best approach is go back to @osmrs however neither me or the others here need to "discuss with Brazilian community" and even the early contact with DWG the osmrs was the channel used by both. To explain why the telegram of OSMRS is relevant, later I will add context (sorry, will be a wall of text) from the date of disaster they appeared on @osmrs and recently moving away while deleting previous messages.). --EmericusPetro (talk)
If you need more help with cleanup and people running this organised edit are failing to clean up after it (note, I have not verified claims made by you) it may make sense to ask local community for help, and/or write at https://community.openstreetmap.org/ and/or contact DWG @EmericusPetro: @Everton Bortolini: Mateusz Konieczny (talk) 18:30, 21 December 2023 (UTC)

(Emerson here, start) I will give a context in English from 2023-09-13 to 2023-12-15, since this situation might escalate (and also to explain that "not discussed in Brazilian community" is misleading as they and DWG know it was the closer group to the region)

  • the cities flooded on 2023-09-05 are on Vale do Taquari, a region in Rio Grande do Sul province, which does have likely one of the more active province-level Telegram in Brazil ( https://t.me/osmrs , or "@osmrs" ). Except by the invitation to map in the initiative (and first weeks, to ask anyone local to be an organizer) on the closest telegram group to the region (which is @osmrs), all decisions were made in closed groups by these organisations.
    • Several promises and general answers from questions were made on @osmrs  by the organisers. However, recently (around 2023-12-15?) one of them deliberately deleted a lot of own messages with these promises (including one promise to prove which mapper/validator was in the city by providing a photo, which is why, unless they prove, we here can say this activity was armchair-only mapping plus Google Street View. As an example of deletion this  https://t.me/osmrs/25899 message today goes 404 not found, but both previous (https://t.me/osmrs/25898) and next (https://t.me/osmrs/25900) are online. Depending on the Telegram client used to see the chat, may or not display if it is replying to a deleted message
  • After their supposedly 100% validation step, it was me from the group who stopped to look. I started to see potential red flags (sense: blatant things which shouldn't even be there after review, and I'm NOT talking merely about non-squared buildings). The start of this was 2023-11-19 <https://t.me/osmrs/25875> and next messages with others in the osmrs group. Yet, the organizers (while very active to invite to map in preview us weeks) with the finalized event simply... didn't reply at all! One peer (@santamariense, which I do respect his work, and he is from the region) suggested we simply mass edit to building=yes could be enough, but there was other issues with fake data with needs non automated verification (plus the need to undelete things)
  • Without the responsible for the Organized Editing replying to the complaint, and no one local with time to carefully review, I started to research how to do a full revert of over 2000 changesets. And with this call in public (where I had to mention all the supposedly organisers, hard to know since it was undocumented ) here 2023-11-20 <https://t.me/osmrs/25898> and saying that unless they took we would revert, this make an immediate response on , we got the initial reply of first attempt to post-validation here 2023-11-20 https://t.me/osmrs/25899 (now deleted) that they would start it review again.* 2023-11-22 DWG contacted [Ticket#2023112210000181] . At this moment, the DWG contact already knew that @osmrs (the province group) was used by both sides, however since the organizers already were attempting to review, it made sense to give more time.
  • The said first post-revalidation revalidation didn't happen in practice. Every one of the mentioned issues in @osmrs telegram chat persisted. For example on 2023-11-19 https://t.me/osmrs/25889 the mentioned shop=clothes (node/4917865622) moved by an armchair mapper (note that even addr:street still use old street)still even today in the live server (this shop=clothes was the initial example of red flag of what could happens even with their review). However, to be fair, one of the global validators (very friendly) which I had open discussion with in changesets actually fixed manually some (not all) the new building= different than yes, but other than him, it's unclear if they don't know how to fix it. Trust me when I say that this is not a typical problem of unsquared buildings any of you would see like in rural Africa, but affects PoIs (and there's people like me to survey if necessary and find these brown MM's)
  • Not only because it was slow to fix it, but unclear if they would do it right, I asked on telegram again 2023-11-27 <https://t.me/osmrs/25926> andthen 2023-12-11 <https://t.me/osmrs/25969>. The reaction of the organizers was that they didn't know at all about https://osmfoundation.org/wiki/Organised_Editing_Guidelines>, from things like not really being their responsibility to fix or have to respond within 2 business days. 'This explain why (in addition to data related requests) the text contains parts about make commitments to acknowledge the OEG in any future event by any of the organisation who coordinated this one They don't want the data to be deleted, but they don't seems to like complains that they need to fix it.
  • A drastic change happened 2023-12-14 when I posted on @osmrs that A) that even the documentation for the Tasking Manager advice to NOT allow beginners edit projects like this and B) year before a global validator  on the question and comments section of https://tasks.hotosm.org/projects/13594 (a 2022 a project of UmbraOSM, one of the 3 organizers) that they're releasing a complex project for beginners and also that the tagging building=residential instead of building=yes and C) that a change on the Tasking Manager this year now allow project admins to delete public messages on the "questions and comments section" and an global validator on the projects in discussion now already had warned about low quality. Immediately after, one of them proposed to move the decisions to whatever the current data (note: there is still both fictitious and even Google copyrighted data) needs reversion from the telegram of the province osmrs to the telegram of the country.
    • Note: while I did not shared on the telegram, the link for the discussion with the global validator was https://www.openstreetmap.org/changeset/143333801, it's in portuguese, but is around  "Nesse meio tempo, também entrei em contato com o organizador ou com meus colegas da HOT sobre a qualidade às vezes ruim do mapeamento."
  • While from my province is me who took the time to investigate the problems (is very, very time consuming) others like Gustavo Schenkel (one of the group admins) on https://t.me/osmrs/26034 explicitly asked if they're following the Organized Editing Guidelines.
  • The last reply from the organisers was 2023-12-15 https://t.me/osmrs/26037 (archive-1 archived-2 ) which, in direct translation means "I wish you all good luck! There is my email in the documentation and I will be on the national channel." (Original message in portuguese: "Desejo boa sorte para vocês! Tem o meu e-mail no documentação e vou estar no canal nacional.")
  • And finally, 'in addition to previous weeks where only changeset and public chat messages about the objections on @osmrs, on 2023-12-19 https://t.me/osmrs/26045 I posted the link to Organised Editing/Activities to have a summary English with examples.
    • If any true local mapper from here ask me to review something (such as make changes on request commitments to OEG; the data problems are less subjective), I will obviously take them seriously. Until now, no objections neither in private nor in public.

(Emerson here, end) --EmericusPetro (talk) 05:57, 23 December 2023 (UTC)

" where it cannot be simply edited at will by the other side" - response is still fine I guess. Can you copy missing parts to 2023 Brazil Floods ? Mateusz Konieczny (talk) 19:38, 23 December 2023 (UTC)
@Mateusz Konieczny: Matheuz and others: if infeasible leave the full compilation on the column "Community objections?" at Organised_Editing/Activities, then make a snapshot from the deleted content of https://wiki.openstreetmap.org/w/index.php?title=User_talk:Everton_Bortolini&curid=312169&diff=2634479&oldid=2633578 at Organised_Editing/Activities/2023 Vale do Taquari Floods/Community objections with a literal copy (and link to where it was extracted, the deletion) and a prominent warning to the organizers NOT to edit the page. The "Vale do Taquari" in the page title (or, less precise but still closer region above, "Rio Grande do Sul") is very important, it is non negotiable. The reasoning is the recent shift to name this "Brazil Floods" (despite all description be from cities in the Vale do Taquari) is not merely geographically misleading, but also attempt to boycott the previous discussions with the local community @osmrs with extensive chat history (part by their side is deleted, but not all) with clear intent to allow armchair mappers from the same organizations who created the event to vote to allow anything (from copyright data to deletion of surveyed data to re-create again). If you or others decide to copy missing parts from the Organised_Editing/Activities/2023 Vale do Taquari Floods/Community objections to 2023 Brazil Floods, then anyone else can do it. --00:50, 24 December 2023 (UTC)
still not investigated it in detail but I noticed part about "it is non negotiable" - I would advise against such claims. Also, not sure has it happened but I would strongly advise against trying to hide that some problems happened, better to describe how they were resolved and will be avoided in future. Neither communication strategy is a good idea Mateusz Konieczny (talk) 13:42, 27 December 2023 (UTC)

Documenting changeset tags separately from element tags

Resolved: Dedicated templated has been created

Changeset tags (Category:Changeset tags) are currently just documented on Key:* pages, which however is pretty confusing, since it conflates changeset tags and element tags in ways that are not immediately obvious. E.g. most of these tags have status=discardable but this of course refers to the usage on elements (since changeset tags in fact cannot be discarded since they're immutable). So e.g. the status of the created_by=* tag should probably actually be "de facto" for the changeset tag. Likewise the {{KeyDescription}} infobox shows the taginfo usage, which of course only refers to the usage on elements but that again is not immediately obvious.

So I think it would make sense to document the changeset tags in a dedicated namespace, perhaps as subpages, e.g:

Key:source, Key:created_by, Key:imagery_used would then only document the usage on elements (like 99% of Key:* pages do) and of course link to the respective changeset tags.

I think that this would clear up the documentation, what do you think? --Push-f (talk) 06:08, 20 July 2022 (UTC)

Maybe Changeset key:created_by or ChangesetKey:created_by instead of namespace that has own baggage would be better? Mateusz Konieczny (talk) 11:20, 20 July 2022 (UTC)
Yeah that would also work. In that case I'd prefer CamelCase. A small advantage of using subpages would be that they would automatically link to Changeset but I guess such a link could also be produced via a template. --Push-f (talk) 04:57, 21 July 2022 (UTC)
On a related note I think we should deprecate use on changesets (P37) and instead introduce data items "changeset key" and "changeset tag" to be used with "instance of". --Push-f (talk) 11:23, 1 August 2022 (UTC)

@Push-f: - are you interested in creating this templates? If yes, then feel free to do so, there was more than enough time to protest/comment and this idea makes sense (I also had this idea, not done it only due to limited time) Mateusz Konieczny (talk) 17:18, 3 November 2023 (UTC)

See also currently discussed issue Talk:Tag_status#Discardable_on_entities,_but_usable_on_changesets. I support establishing a namespace for changeset keys. Camel case ChangesetKey: would be fine! -- Chris2map (talk) 19:18, 3 November 2023 (UTC)

So how? ChangesetKey:created_by -- Something B (talk) 23:09, 3 November 2023 (UTC)
@Something B: Yes, but the "whole system" (templates and module) needs to be educated and adapted to it, I must admit. See Template_talk:ChangesetKeyDescription.
An alternative could be one of these notations for the pagenames:
  1. Key:(Changeset) created_by – example
  2. Key:Changeset - created_by
  3. Key:-Changeset- created_by
  4. Key:Changeset/created_by
  5. Key:Changeset//created_by
I like no.1 too. Should be working without reworking the module. --Chris2map (talk) 13:49, 4 November 2023 (UTC)
I think that splitting the documentation into two articles isn't a good idea.
First: links from the main OSM website will still direct to Key:created_by: https://osm.org/changeset/100000000
Secondly:
  • the [created_by] tag as a tag used in the main database actually only needs an infobox: with usage statistics, status, description, just like any other tag or key in the database.
  • for that [created_by] as a tag used in the changeseet needs a description, but for that it doesn't need an infobox at all with information on whether it is to be used on nodes or not, because it is not used on Elements at all. Thus, I would leave it as it is. Alternatively, you could make it so that on one page there is a description of both the changeset key and the key from the main database, separated by a horizontal line, for example: [2]. maro21 21:48, 7 November 2023 (UTC)
The first point (link from an OSM changeset) is an important note but I'd say that could and should be updated. Does anyone know if OSM website uses the documentation links from the data items (like iD editor) for these tag links?
To the secondly points: I prefer to document changeset keys or tags separately from the element tags. I'm with you that changeset tag pages don't need the element tag infobox, or at least an new infobox with different layout (neither tag descripition nor feature description). So I would use ChangesetKey: and ChangesetTag: pages with new distinct layout. Or should we abstain from those separate pages and list (document) all changeset tags on one single main page?
In addition the element tag pages could get a uniform link notice to the documentation place of the changeset tag of the same name. --Chris2map (talk) 18:01, 8 November 2023 (UTC)
@Chris2map: The part of the infobox that says which element types you can use the key/value on now includes an icon indicating whether it's a valid changeset key/value, based on use on changesets (P37). With this change, pages like clacks_overhead=* can be documented as "in use" without causing as much confusion. – Minh Nguyễn 💬 18:22, 10 November 2023 (UTC)
I have to say that it is not clear to me how the different nature of element tags and changeset tags can be recognized and how we want to provide different information for e.g. status or combinations etc. in the description box. In case of single wiki page that would then need at least an additional box for the changeset use case. IMHO, the additional icon is far from enough to make these different cases recognizable and understandable. --Chris2map (talk) 08:11, 11 November 2023 (UTC)
@Chris2map: That's true, but I would consider it just another case of homonymous keys where the usage differs by element type. Otherwise, if we relegate changeset usage to a separate page, we have to work harder to make that page discoverable than if it's in a separate section on the same page. For OpenHistoricalMap-specific tag definitions, we're relying on {{See OpenHistoricalMap}} to make the OHM page more discoverable, but for changegset keys/tags I think that would make it look like more of a special case than it is in reality. – Minh Nguyễn 💬 22:34, 11 November 2023 (UTC)
@Minh Nguyen: I see your point with fragmented and findable documentation. To jump to the start of this discussion: Look at the very first 4 sentences. It is an important thing to clear a status of an element tag to me too. Meaning, if e.g. usage in the map (on elements) was discardable that should be provided on the tag page to users and software (like taginfo). In such a case a different status, since usage on changesets is active, wouldn't be appropriate to me. This leads to 2 statuses on one page or to no status for the changeset usage. The former is currently tested on Key:created_by but in this way it is no solution and increases confusion rather than reducing it, IMHO. Then I would prefer to leave out the status for the changeset use. --Chris2map (talk) 08:10, 12 November 2023 (UTC)
@Chris2map: I concede that there’s a tradeoff in terms of being able to definitively state the discardable status of an otherwise acceptable key for changesets. To me this is similar to the situation with type=*: deprecated on nodes and ways, but required on relations. – Minh Nguyễn 💬 18:54, 14 November 2023 (UTC)
@Minh Nguyen: I obviously make a much bigger distinction between the two cases (changeset and entities). To be honest, when it comes to changesets, I would prefer not to even talk about the terms tags and keys. For me, these belong to map elements and map features and I therefore see a fundamental risk of confusion if it is not treated separately for changesets (not in technical way but in terms of feeling). But I definitely don't want to be petty here. The current path is already a big step forward and will result in a good tradeoff. But it would be nice if we weren't the only ones writing "ping" pong here. What do others think? --Chris2map (talk) 19:19, 14 November 2023 (UTC)
"Does anyone know if OSM website uses the documentation links from the data items (like iD editor) for these tag links?" - no, it links and check OSM Wiki pages Mateusz Konieczny (talk) 08:51, 13 November 2023 (UTC)
@Mateusz Konieczny: Actually I think it’s just hard-coded to point to the articles. [3][4] – Minh Nguyễn 💬 18:54, 14 November 2023 (UTC)
"only needs an infobox: with usage statistics, status, description" - well, their status is different Mateusz Konieczny (talk) 08:50, 13 November 2023 (UTC)
I took the liberty of carrying out a test with a layout variant (proposal of styling) to Template:ChangesetKeyDescription (using Template:Description/sandbox). Style is derived from changeset view on www.openstreetmap.org/changeset/... – Have a look at Key:created_by and Key:imagery_used. – What's your opinion? --Chris2map (talk) 17:52, 13 November 2023 (UTC)
The parts of the infobox that come from the data item might need some extra attention, since an article can only be linked to a single data item at a time. What we can do for these cases is to qualify the status (P6) statements with one or more “applies to” qualifiers that the modules can look at. This would be useful not only to the infobox but also anything else that’s using the data items directly. If there’s support for this idea, I can create the necessary property. – Minh Nguyễn 💬 19:06, 14 November 2023 (UTC)

Is having a list of tags for each coastal community a good idea?

Resolved: see below Something B (talk) 09:21, 5 November 2025 (UTC)

See Veneto/Lagune e zone umide/Laguna di Venezia and Talk:Veneto/Lagune e zone umide/Laguna di Venezia - maybe replacing this tables by links to more generic listing would be a good idea? Mateusz Konieczny (talk) 13:07, 1 August 2022 (UTC)

This is an article from the prehistoric times, when there may not have been what we have now. I haven't read into it and analyzed it, but I think that instead of deleting it, it would be a good solution to move it to user space. Or leave it. Or marked it as not up to date. maro21 20:44, 19 April 2023 (UTC)
Commented on https://wiki.openstreetmap.org/wiki/User_talk:Bigshot#Veneto%2FLagune_e_zone_umide%2FLaguna_di_Venezia Mateusz Konieczny (talk) 10:10, 5 November 2023 (UTC)
That page used to be a working reference for the local mappers group.
I think it's a good idea to move up references to all the main page for each (not only Waterways) map feature indicated with a big warning about the importance of checking there any update about keys and values.
At the same time deleting that page would be a big error since it's a good help for local mappers: local words, non even in italian, are still widely used and this "local dictionary" is key to prevent lack of homogeneity inside the same actual part of the map. This is actually a very heavy problem in Venice with all the tourist mappers keeping a very chaotic set of different standards. Unfortunately the local mapper group didn't live long enough to complete the task.
In the meanwhile i would just mark it as not up to date as suggested by maro21 --bigshot (talk) 14:48, 8 November 2023 (UTC)

Global policy with Commons, should we move files from OSM wiki to Commons

I recently saw the use of the {{Move to Commons}} template, and added it to a File:Street Side Parking.png file, @Dcapillae: had a good thought on the talk page (File talk:Street Side Parking.png) and that's why I'm starting the think here:
Should we move files to Commons? If not, why ? If yes, which files should we keep and which files should we move?

For my part, I have personally tried to put as little as possible on OSM Wiki (especially things that are impossible to put on Commons like Maxar satellite imagery). But I didn't think further. Can we trust Commons ? Should we trust Commons ? What could we gain by moving some of our files there ? Is it really useful? etc.


Besides, I want to thank @Mateusz Konieczny: for the work of cleaning and tidying up because it is not easy to do and it requires courage! By the way, this work of cleaning at OSM Wiki will have to be done anyway, no matter what our position is towards Commons, to make sure that copyright is respected in our free project on the Wiki. — Koreller (talk) 20:36, 25 November 2022 (UTC)

"Can we trust Commons ? Should we trust Commons ?" - I think so, they are relatively stable and well managed. Though maybe making backup of files we are using is a good idea - good project for anyone suspecting trouble. this may be a good first step Mateusz Konieczny (talk) 21:44, 25 November 2022 (UTC)
"What could we gain by moving some of our files there ? "
Free photos are more reusable and easier to find by others (better categorization, more normal location, more trustworthy in general)
Photos uploaded to Commons are immediately usable on Wikipedias and other Wikimedia projects making easier to illustrate OpenStreetMap articles across Wikipedias (or other related articles with OSM-related content)
Better review of licensing situation (for example, photos depicting modern statues in France are problematic due to FOP situation - there are some people on Commons aware of such traps and acting on it, while here for multiple years we had massive amount of clear copyright violations and noone noticed. Some were clearly labelled.). Though that is a bit of tough sell, as in other words it is "maybe your photo will be deleted due to obscure stupid laws"
Forces us to review licensing situation (again a bit tough sell, but it is worth doing)
Encourages people to upload to Commons in the first place. They have much better upload interface, ours is basically broken - see [5] [6] that results in well intentioned people uploading own photos and ending in limbo legal status anyway which is tremendous waste
Commons has some special tools like license verification bots allowing to confirm Flickr license claimed during upload
During transferring files often one finds clearly superior versions. For example this soon to be deleted local version is of much smaller resolution than full photo that I found during transferring it
Mateusz Konieczny (talk) 21:44, 25 November 2022 (UTC)
"I have personally tried to put as little as possible on OSM Wiki (especially things that are impossible to put on Commons like Maxar satellite imagery)" - and thanks for that, in case of uploading them locally it is likely that you would miss license or even worse "that is my own work" claim that would make things complicated. Also, such uploads are far more likely to be used by others (I benefited from that during StreetComplete development that people uploaded stuff to Commons rather some local wiki) Mateusz Konieczny (talk) 21:48, 25 November 2022 (UTC)
Wikimedia Commons is a separate project, and I don't see any reason to force someone or suggest moving. If a person who adds the template wants to use a file on Wikipedia or a similar project, they can always make a copy on Commons - it is not forbidden as long as the license is compatible. I think OSM-related files should be here, because in case someone wants to upload a new version, they will do it here. The {Move to commons} is a copy of a template from Wikipedia, which was created not to keep images on just one Wikipedia, but to make them available on Commons, so that other Wikipedias can use the image too. In our case, it is unnecessary. Besides, I think most of the files we upload here don't fit on Commons. maro21 20:59, 19 April 2023 (UTC)
@Maro21: "I don't see any reason to force someone or suggest moving" - main reason is that we are incapable of even reviewing images for copyright violations, osm-related images on Commons will be more widely reusable (for example on Wikipedia), we have major trouble with setting up upload interface and so on Mateusz Konieczny (talk) 12:46, 15 December 2023 (UTC)
"Besides, I think most of the files we upload here don't fit on Commons" - not really, only images which use proprietary imagery like Bing and images here on fair use (complex logos of sponsors) are out of scope of Wikimedia Commons. Mateusz Konieczny (talk) 12:46, 15 December 2023 (UTC)
Resolved: discussed, will link it from template talk page Mateusz Konieczny (talk) 20:30, 2 November 2025 (UTC)

Photo for SoTM, no evidence of a license (any)

Resolved: file deleted [7], images replaced, see also [8] --Chris2map (talk) 18:36, 12 November 2025 (UTC)

Photo from third-party, license not mentioned at all: File:Libya3.jpg. Something B (talk) 14:54, 9 November 2025 (UTC)

Uploader was recently notified in https://wiki.openstreetmap.org/wiki/User_talk:Kateregga1#License_of_images_on_State_of_the_Map_Africa_2023/Call_for_venues/Libya Mateusz Konieczny (talk) 07:17, 11 November 2025 (UTC)

Redirect pages for keys and tags

Is there anyone else who finds redirect pages for keys and tags an obstacle for the access of information? If there is no page for a key or tag, the description box is displayed nevertheless (e.g. Tag:location=platform). But if the page was created with a redirect there is no content, no description box. As a result you didn't get displayed information available from taginfo (usage) and/or the corresponding data item. On the one hand that makes it more difficult to obtain the information, on the other hand it disables accessing / maintaining data of the data item. And languages bar is also missing so you cannot find the page in other languages that may exist.
I suggest one of these two options:

  1. Not to create redirects for keys and tags, but stub pages with the description box and a link to the page, that would be the redirect target, at least.
  2. Place a bare description box template after the redirect to display the description box (in order to have the links to taginfo and data item and show information from data item if available). For this I created the Template:Description/nocat that reduces categorization of those redirect pages to a minimum. The page content then would be
#REDIRECT [[...]]
{{Description/nocat}}

See e.g. Key:addr:door.
The reason for a bare template is that we don't want to maintain page content on a redirect page, I guess. --Chris2map (talk) 07:34, 26 July 2025 (UTC)

See also Key:dual_carriageway that redirects in prose. I like both solutions Mateusz Konieczny (talk) 05:24, 5 October 2025 (UTC)
Resolved: seems answered Mateusz Konieczny (talk) 07:31, 11 November 2025 (UTC)


New tag and Wiki label "invented tag"

At Any tags you like it says "You can use any tags you like, but please document them here on the OpenStreetMap wiki ...". So it is recommended to document an invented tag, probably with a key or tag page. This leads to the issue that the new tag might look like an established tag or a tag with community support at least. Since I believe that an established tag should be recognized as simply and clearly as possible, or conversely, an invented tag should also be recognizable as such, I see two possibilities:
1) Change the guideline and recommandation so that a tag page is not created until the invented tag receives support through discussions.
2) Enhance / extend the guideline and recommandation that the nature of tag as new invention should be clearly expressed and how this can be achieved. – For the latter I want to propose the tag / Wiki label "invented tag". I created a template for example - {{Invented tag}} - based on the existing {{Undocumented tag}}. – What do you say about the topic and the proposal? --Chris2map (talk) 14:01, 30 August 2025 (UTC)

I am in favor of second variant. Something B (talk) 14:08, 30 August 2025 (UTC)
At first glance, I am not in favor of either of these proposed changes. Option 1 means stronger "notability" gatekeeping which is the thing that pushes many people, including me, away from Wikipedia editing. Option 2 is similarly judgmental, and either self-fulfilling or quickly becomes outdated.
For someone to go through the effort of developing a tagging schema, putting it into use, and documenting it here on the Wiki, just for the page to be deleted or red-marked as "invented" (which all tags are, so at bare minimum Option 2 would need to use a different term) is really discouraging and is the exact opposite of the direction we should be heading.
To offer an alternative that sidesteps these issues: how about incorporating automatically-added notes to the existing, widely-used TagDescription (and related) templates that, based on objective statistics from Taginfo, flags tags as low-usage (via either an absolute number of instances, an absolute number of users, or some function relating the two)? Lumikeiju (talk) 05:44, 2 September 2025 (UTC)
Thank you for your replies and thinking! I admit, I looked at the whole thing from a maintenance perspective. With the advice on avoiding hurdles or deterrent regulations, you have focused attention on a crucial topic. – I am looking for solutions / improvements that make it easier to react to issues such as: A) In discussions, it's often pointed out that there's a wiki page for the tag, so it's good to use. This means that the mere existence of a wiki page is often cited as official recognition or at least as a measure of the quality and validity of a tag. No matter of the factual usage. B) I understand that not everyone can or wants to create a formal proposal with such strict form. But why should anyone even create a proposal if documenting a tag via a tag page has more or less no restrictions? C) I think it might be helpful to create a tag page right away to have documentation that can be discussed. (Something like a proposal light.) I just want some kind of recognizability. D) We currently have few direct options for maintaining the wiki to distinguish between pages with wide spread tags and those with not established tags, which becomes more important as more pages are created on the latter. (The only thing is status "approved" and maybe "de facto", but for "in use" it is unclear.) Unfortunately, the taginfo statistics (usage count) are only visible when the page is accessed. They're not helpful in the categories (e.g. "Category:Tag descriptions for XY..."). Whether further, deeper relations are possible here is beyond my knowledge. – Perhaps, as you suggested, we need to go the other way and give the established ones an additional mark. --Chris2map (talk) 15:43, 5 September 2025 (UTC)
"But why should anyone even create a proposal if documenting a tag via a tag page has more or less no restrictions?" - to get feedback and confirm that invented tagging scheme has no major issues and that at least some specific subsection of community likes it (peer review is not magic and does not guarantee good effects, see science, but can be useful, see science) Mateusz Konieczny (talk) 02:56, 4 October 2025 (UTC)
"In discussions, it's often pointed out that there's a wiki page for the tag, so it's good to use" that is just wrong given that we also outright have pages stating "this tag is a horrific mistake for following reasons". When such terrible and wrong argument appears this should be explained to mistaken person, rather than deleting all pages for bad tags Mateusz Konieczny (talk) 02:58, 4 October 2025 (UTC)
I am in favor of second variant. I hate overtemplatification and I used following method when describing one of own inventions: separate section "Popularity" with "Note that as of early 2020 majority of uses of this tag is by a single person in a single city<ref>[[User:Mateusz Konieczny]] mapping in Kraków, Poland</ref>." Mateusz Konieczny (talk) 02:54, 4 October 2025 (UTC)
I've realized that adding another label and box isn't ideal. Therefore, I've decided to scrap my template proposal. It's important that the description on one page clearly explains the tag's origin and use, and links to relevant discussions. – Improvements are still possible in the guidelines and our currently existing tag status (reduce them?). --Chris2map (talk) 18:18, 26 November 2025 (UTC)

This page is overly large - please help

This page is large enough to cause technical issues and we were asked to trim it.

If you see already resolved section: feel free to apply {{Resolved}}

If you see section where you can do something to bring it toward closure: it would be appreciated.

If some section become irrelevant, stuck etc... Maybe you can at least propose there action that could bring it to closure?

Mateusz Konieczny (talk) 20:59, 2 November 2025 (UTC)

Resolved: looks trimmed! Mateusz Konieczny (talk) 05:39, 29 November 2025 (UTC)

Screenshot of Google Maps

Resolved: deleted --Chris2map (talk) 09:08, 23 November 2025 (UTC)

File:Track of izola.png — fair use in this case seems to be dubious.

Removed from https://wiki.openstreetmap.org/w/index.php?title=Tr:LLLMapping_Project&diff=prev&oldid=2918599 - fair use is not applicable at all as it could be easily shown on OSM background and as far as I see nothing required GMaps specifically Mateusz Konieczny (talk) 14:35, 12 November 2025 (UTC)

Images from OpenStreetCam

Resolved: deleted --Chris2map (talk) 18:31, 27 November 2025 (UTC)

File:OSC_nearby_image.gif — If individual contributor must be attributed (same as for Mapillary), we likely can't retrieve necessary info, and can't fix such images. Something B (talk) 11:10, 17 November 2025 (UTC)

The individual contributors / photographers are attributed in the image above the photos. Or did I misunderstand what you meant? --Chris2map (talk) 17:46, 26 November 2025 (UTC)
My mistake, I meant File:OSC selected aggregated detection 2.png. Something B (talk) 23:39, 26 November 2025 (UTC)

How does one add a web font for use in-wiki?

Resolved: Question was answered. --Chris2map (talk) 19:11, 3 November 2025 (UTC)

In translating pages to Punjabi, such as Pnb:لُغت, I have been using Template:Nastaliq combined with some external font links in my custom Common.css file to get the script to render in the Nastaliq style. Essentially what this does is it uses different letter shaping and connecting patterns than would be seen otherwise. This has an impact on legibility, as languages such as Punjabi or Urdu are typically only written this way. Wikipedia includes Nastaliq web fonts for rendering these languages for reference, so this is something that users on that platform would be used to. Unfortunately, Android is a holdout in including a Nastaliq font by default, so hosting a web font is the best option at the moment.

The font I would like to include if possible is the Gulzar font, available at gulzarfont.org, which does a good job at rendering text in a "non-calligraphic" way while remaining true to the typical letter styles of Nastaliq typefaces. --Bgo eiu (talk) 22:49, 1 October 2022 (UTC)

@Bgo eiu: Ideally, MediaWiki would bundle a suitable Web font as part of the Universal Language Selector extension, which is installed here. That would allow users to click on " پنجابی" at the top of the page, then go to " ڈسپلے ترتیباں" and "لپیاں", then change "پنجابی لئی فونٹ چݨو" from "سسٹم فونٹ" to Gulzar. I see that you've already requested the addition of Gulzar to ULS. If a workaround is urgently needed, it might be possible for a user script or gadget to embed a Web font using a massive data: URI in an @font-face rule, but I don't think it would be a good idea to enable by default for performance reasons. An externally hosted font would get around some of that issue, but it would present both privacy and security risks. – Minh Nguyễn 💬 21:15, 11 October 2022 (UTC)
Ah, I assumed this would have to be implemented separately for different media interfaces, in that case, the Phabricator ticket should be fine. It's not urgently needed; I use an external URI with @font-face in my user settings but this is not really needed in the CSS once that goes through. --Bgo eiu (talk) 23:37, 11 October 2022 (UTC)
@Bgo eiu: I'm not entirely sure about the mobile view. There doesn't seem to be a way to access ULS from there, other than to switch to the desktop view. – Minh Nguyễn 💬 09:08, 12 October 2022 (UTC)
@Minh Nguyen: Are the ULS hosted fonts accessible from the CSS? I forget to check what things look like in the mobile view because I set everything to desktop mode to get the missing features anyway. That may be something that's hard too do much about short term, it shouldn't be anything that's too much effort on the wiki's part to implement. Google developed the Nastaliq font that iOS includes by default, it could be a matter of finding the right Android developer's e-mail address. --Bgo eiu (talk) 03:55, 14 October 2022 (UTC)
@Bgo eiu: Not sure, but you can use the mobile view from your browser and inspect the loaded fonts in your browser's Web inspector. It could be that the fonts do load despite a missing ULS UI. The mobile view does load gadgets and user scripts like normal. – Minh Nguyễn 💬 02:13, 2 November 2022 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Wiki/Archive_12&oldid=2927863"