User talk:Minh Nguyen

From OpenStreetMap Wiki
Jump to navigation Jump to search


I noticed you seem to have a preference for using the SR ## format for state routes, rather than US:OH ##. Is there a practical reason for this, to explain why you re-did all the ref tags on Columbus's West Innerbelt (US:OH 315)? I prefer the US:OH format, because it indicates what state. Maps should make that distinction, too — I've not drawn (even by hand) a map that uses a simple circle for a state route since I was about 10 years old. Then again, when the route relations are done, and the renderers use those, it will be a moot point. Vid the Kid 05:21, 18 April 2009 (UTC)

See User talk:Vid the Kid.
These entangled threads of discussion further continued at User talk:Vid the Kid.

Ref for Overlapped Routes

I also just noticed you set Harrisburg Pike to "ref=US 62" and "ref_1=SR 3". I'm pretty sure that's not the way to do it. Faq#What_shall_I_do_for_roads_that_have_multiple_values_for_a_tag? That entry only mentions using relations, and using a semicolon to separate multiple values in a single "ref" tag. The whole _1, _2, etcetera business seems to be a TIGER thing and I don't think applying it to native OSM tags like "ref" will accomplish anything.

It would certainly be nice if the renderers actually displayed overlapped routes nicely. As it is, they don't seem to do anything special with the relations or semicolon-delimited ref tags. Vid the Kid 05:35, 18 April 2009 (UTC)

See User talk:Vid the Kid.
These entangled threads of discussion further continued at User talk:Vid the Kid.

Route 4 != Dixie Highway

You have labeled the route relation for US:OH 4 as "Dixie Highway". I believe that to be incorrect. After a small amount of research, it seems that the Dixie Highway in Ohio followed Route 4 from Cincinnati to Middletown, then hopped over to Franklin on route 73, and from there followed US 25 to Toledo. Wikipedia:Dixie Highway, Wikipedia:File:Dixie Highway Map.gif, 1932 Ohio Map

I believe the Dixie Highway should have a route relation for its two main branches, but this should be separate from US:OH 4. However, United States Numbered Highway Relations doesn't have a section for all historic roads, just National Scenic Byways. The Dixie Highway is not in the NSB program. Similarly, the Lincoln Highway is in the NSB program, but only the Illinois segment. I think I'll suggest on that talk page to expand that section to include other (and full lengths of) significant historical roads. Vid the Kid 21:28, 30 June 2009 (UTC)

See User talk:Vid the Kid.

US 42 is apparently north/south in Ohio

I've just noticed that the "direction of survey" for US 42's straight line diagrams are all "north". Therefore, I've noted on the relevant Wiki pages that US 42 is north/south in Ohio. I've already changed the roles for the member ways in downtown Cincinnati as part of a larger route clarification and relations effort. (I can't recall what directions are used on actual signage in my area, but it wouldn't surprise me if it's inconsistent.) Vid the Kid 09:36, 24 September 2009 (UTC)

See User talk:Vid the Kid.

You may have a point about the SLDs not being entirely authoritative regarding directions. As another example, I-270's survey direction is "north" in the clockwise direction. But I'm not sure one can expect the SLD survey direction to match the signed direction on loop roads. Still, part of I-270's SLD makes reference to US 62 NB, while US 62's survey direction is "east". (I personally think US 62 should be north-south, but that's another issue altogether...)

I suppose I should try to do some field checking for US 42 before we go to too much trouble changing stuff. For the most part, ODOT uses the US 42 shield with no directional auxiliary signs, but I know of a couple of places where there should be some. Vid the Kid 18:02, 24 September 2009 (UTC)

Update: Field checking done from LaFayette to Delaware. When used, direction signage is consistently "north" and "south". Vid the Kid 21:37, 25 September 2009 (UTC)


Anh Minh giúp mình với, mình sửa bản đồ ở chế độ áp dụng ngay nhưng không thấy nút lưu, không biết cách nào để lưu cả, chỉ với--Magicknight94 00:24, 28 September 2009 (UTC)

Xem User talk:Magicknight94.

Re: Townships

See User talk: Vid the Kid. I like to keep both sides of a discussion in one place. (Reply count: 3) Vid the Kid 09:25, 27 October 2009 (UTC)

Leaflet in vi.wp?

Can you give me please an example link to your edit. I want to try and compare leaflet but if I look at I see only a link to WikiMiniAtlas. I want to upgrade the documention. --Kolossos 19:45, 27 September 2012 (BST)

See User talk:Kolossos.

CLDR is an unreliable, inconsistent source for Vietnamese names

Sorry that I don't speak Vietnamese. Could you describe me please more what's the problem was with my import. You change 10 of the 200 countries, would you say my import war in summary acceptable or more a disaster? I believe also manually translations would have some mistakes.

My next plan is to translate all capitals by using Wikipedia interwikilinks and Add-tags. Do you think that's a better source?

My second larger plan is to translate states in ISO 6133-2 by using a debian package. So it's the top-to-down way for zoomlevels 0-6, which we already have in Wikipedia in different languages. Later we need for Multilingual maps Wikipedia project more users for translations. --Kolossos 18:46, 15 October 2012 (BST)

See User talk:Kolossos.

USBR 25 in Southwest Ohio

See User talk:Stevea.

Thank you for your excellent edits everywhere, and nice to "meet" you (we've brushed up against each other in the talk-us pages regarding boundary=census and other topics).

I've added relation 3087492 as a SW Ohio USBR 25 candidate relation based upon your OKI data of where it goes. I agree with you that overloading the UGRR relation is incorrect, so thank you for deleting that relation from the USBR table. However, I believe 3087492 is either mostly or entirely correct.

—Preceding unsigned comment added by Stevea (talkcontribs) 19:48, 17 July 2013 (UTC)

Tag pages for Highway networks


your creating a lot of pages with highway tags for each county:

What is the intention of this pages. What will be it's content?

Wouldn't it be simpler to just add a page for all highway networks in Ohio?

--Werner2101 (talk) 12:16, 25 May 2014 (UTC)

(moved from talk:werner2101)
There is, but I've been creating separate wiki pages so that Taginfo can describe each value specifically. Descriptions are especially useful for network=US:* because many values include abbreviations that may not be familiar to every mapper. – Minh Nguyễn (talk, contribs) 12:20, 25 May 2014 (UTC)
This creates a lot of noise in the wiki. Not every tag needs a tag description. Consider what will happen if someone starts to add tag pages for each name tag. You can use Overpass API to get all Highways with a specific network tag. --Werner2101 (talk) 12:27, 25 May 2014 (UTC)

(moved from talk:werner2101) Names don't need descriptions. Separate pages make sense for network=* because its values are all abbreviated, not spelled out like cuisine=* or denomination=*. There would eventually be no more than 88 pages for Ohio county route networks, and each of them would tell you what the abbreviation means, an example route shield that a renderer is expected to use for each route in this network (also displayed in taginfo), and the standard format for the ref tag on member ways (CR 123, C-123, CH 123, etc.). Is the problem that I'm cluttering up Special:RecentChanges? If so, I'm pretty much done, because we've only added route relations in a few more counties. Taginfo already knows how to parse pages like Map Features; I'll file a bug requesting that it parse additional pages where we can aggregate all this information. Sorry for the inconvenience I've caused you today. – Minh Nguyễn (talk, contribs) 12:39, 25 May 2014 (UTC)

Im not worried about the cluttering of the Recent Changes list. The tag pages are cluttering all the categories of the tag descriptions. (e.g. Category:Tag descriptions) where all tags are listed.
The created tag description don't contain any description. It is just a simple forwarding to Ohio/Route relations. I think a single page about mapping US highways would be more helpfull than several hundred Tag:network=US:XX:YY pages. Ohio is not the only state in US. US is not the only country that uses road route references. --Werner2101 (talk) 19:08, 25 May 2014 (UTC)
The description is in the {{ValueDescription}} box on the right; that's what taginfo is using. But I can add more information to the body of each page, too. Ohio is one of two or three states that use separate network values for each county, because each county has a completely distinct route shield design; most states are using a single US:*:CR network instead. The pages I've created make up about 1% of Category:Tag descriptions and 0.5% of Category:Tag descriptions by value. Even if I were to create a page for each of the 444 values of network being used anywhere in the world – which no one is proposing to do – that would only total 23% and 11% of the respective categories. Still, to allay your concerns, I've modified {{DescriptionCategories}} to exclude these pages from Category:Tag descriptions as long as Category:Tag descriptions for key "network" exists. (See Tag:network=US:OH for example.) The changes will take effect once the wiki's job queue (currently at 1,485) finishes processing the affected pages. – Minh Nguyễn (talk, contribs) 22:22, 25 May 2014 (UTC)


If you really want to humour the fruity hipsters you can write {{languages|Category:macOS}} similarly to iD.--Andrew (talk) 09:04, 1 October 2016 (UTC)

:^D – Minh Nguyễn (talk, contribs) 18:53, 1 October 2016 (UTC)

GeoMapTool / geoBingAn

Just to let you know since you've contributed most to the page, I've added a big fat warning to the page. Versions of this software have caused a huge amount of damage and wasted a lot of time (especially of on-the-ground mappers, but also of the ours at the DWG) trying to clean up the mess. I've also removed the website and store links. Problems caused by this software have included creating dozens of versions of the same object (applying a change over and over again), creating dozens of duplicates of objects, and adding all new nodes at latitude -1. The OSM wiki really shouldn't be recommending this as an iOS editor (as it did at ). --SomeoneElse (talk) 08:39, 20 June 2017 (UTC)

See User talk:SomeoneElse.

Simple 3D buildings software list

Hi, I'm not entirely convinced of your decision to order the software list on Simple 3D Buildings alphabetically. It was closer to a chronological sort order before (although not entirely) – wouldn't it make more sense to keep that basic idea and maybe add a "release date" column to make the sort criteria visible? Disclaimer: This would place my own renderer higher up, so of course I'm biased. ;) --Tordanik 14:33, 2 September 2017 (UTC)

See User talk:Tordanik

Comparison of iOS applications

Minh, I really appreciate your efforts on this comparison page you created in 2016. However, some of the information now seems to be outdated, as many of the apps have upgraded their features in 2 years. I especially noted that ViewRanger had "No" for many things in each table that I see on their FAQ that they actually do. The same seems to be true for some other apps as well. Parsa9 (talk) 16:20, 18 April 2018 (UTC)

See User talk:Parsa9.

rural residential roads with 55mph maxspeed

the way I understand highway classes, a rural road with 55 mph maxspeed shouldn’t probably get classified as residential, I would think unclassified seems more appropriate. —Dieterdreist (talk) 10:12, 29 April 2018 (UTC)

See User talk:Dieterdreist.
I have replied on the linked page. --Dieterdreist (talk) 08:56, 30 April 2018 (UTC)


Congratulations! You are now an adminisrator on this wiki. Please use your new tools wisely, and in servce of our mission. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:45, 15 March 2019 (UTC)

Thank you, Pigsonthewing! – Minh Nguyễn 💬 05:00, 17 March 2019 (UTC)

Deletion policy

Dear Minh Nguyen,

We would like to invite you to voting in the case of the proposed Deletion policy for wiki pages and files. Based on the input of several contributors, we drafted a deletion policy over the span of two and a half months. Among other things, the policy proposes a centralised discussion page for all cases which are not mentioned explicitly.

Kind regards, EzekielT

PS: I wrote this message on your talk page, because you were involved in a long dispute about deleting in 2018 and 2019 which now led to this policy draft. — EzekielT (talk) 18:05, 16 April 2019 (UTC)

Fixing some interface links for me

Hi! I saw that you edited some interface pages and I would like to ask you to fix some for me

MediaWiki:Privacypage should be set to osmf:Privacy Policy
MediaWiki:Disclaimerpage should be set to Disclaimer
MediaWiki:Disclaimerpage/de should be set to DE:Disclaimer
MediaWiki:Disclaimerpage/sv should be set to Sv:Disclaimer

Would be great! --Tigerfell This user is member of the wiki team of OSM (Let's talk) 21:07, 18 April 2019 (UTC)

OOjs UI icon check-constructive.svg Done – Minh Nguyễn 💬 04:41, 19 April 2019 (UTC)

Key:maxweight discussion page

Hey Minh Nguyễn, I wrote you about a mistake on your recent edit on the Key:maxweight discussion page, would you have a look? --Westnordost (talk) 21:06, 24 April 2019 (UTC)

See Talk:Key:maxweight.


While insults on the talk page are embarrassing and there are entire screens of text there - is there anything wrong with article itself that would justify such strong warning template? "for the time being" - when you plan to remove this template? Mateusz Konieczny (talk) 17:33, 1 May 2019 (UTC)

@Mateusz Konieczny: I’m on my phone, so pardon my slowness in taking care of next steps. If you feel that the page is accurate and the dispute is not relevant to the page’s contents, please feel free to remove the warning. I haven’t even gotten halfway through the talk page to know whether there’s any substance to the dispute. Minh Nguyễn 💬 17:42, 1 May 2019 (UTC)
"whether there’s any substance to the dispute" - not sure. I stopped reading it after both participants started using unacceptable insults, ignored hints that writing entire pages of text is not optimal communication method and stopped discussing how that page may be improved. But based in talk-us mailing list discussion and earlier discussion it seems that the page itself seems OK (note, I am highly biased as one of the main authors) Mateusz Konieczny (talk) 17:46, 1 May 2019 (UTC)
Got it; thanks for the clarification. I've removed {{Warning}}; feel free to also remove {{Disputed}} if you feel that the factual dispute is also resolved. – Minh Nguyễn 💬 19:21, 1 May 2019 (UTC)

Search engine improvements/template boosting?

Hi, what became of the ideas that we have discussed in Talk:Wiki#Proposal:_new_namespace_for_tagging_proposals? I think any little improvement would be welcome.. maybe we should create a new section at Talk:Wiki for this? Technically.. I am surprised that there doesn't seem anything like "page rank" in the search engine, perhaps we could use something like an artificial page rank - having articles with manually QA reviewed templates? RicoZ (talk) 22:18, 9 May 2019 (UTC)

OSRM support for time-based turn restrictions?

I'd like to try to improve the data on some time-based turn restrictions in my area, but I'm not confident in doing so without being able to test my work in a routing service that allows me to specify different times. Here you added a claim that OSRM supports time-based turn restrictions. In what sense? The frontend at doesn't give me a place to enter the time. The most recent information I could find about backend support for time-based turn restrictions was in this issue, which indicates that there isn't real support. Am I missing something or should the claim be removed from the wiki? (And as an aside, do you happen to know of another routing service I could use?) Thanks! M3232 (talk) 00:33, 17 May 2019 (UTC)

@M3232: OSRM supports applying time-based conditional turn restrictions as of the time the request is made. This is orthogonal to finding the optimal route as of an arbitrary start time. Valhalla doesn't support arbitrary start times either. I'm not very familiar with other OSM-powered routing engines like OpenRouteService and GraphHopper, but they don't seem to offer this feature as part of their public APIs at least. The conditional restriction syntax is based on the opening hours specification, so you may be able to check your syntax using the evaluation tool or YoHours. – Minh Nguyễn 💬 04:33, 12 June 2019 (UTC)

Changing the calendar

Are you still interested in changing the calendar? Otherwise, I would set up TigerfellBot to update the current implementation automatically. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 08:52, 22 May 2019 (UTC)

@Tigerfell: Thanks for your patience. I've made all the planned changes to the calendar. I like your idea of using a bot to archive the page; let me know if you need help with that. – Minh Nguyễn 💬 01:36, 13 June 2019 (UTC)
I do not really have the time to work on that now, but let's see in about a month. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 22:24, 13 June 2019 (UTC)

Continued issues with SteveA

Hi. Sorry to bother you with this again, but I am continuing to have issues with SteveA and I was wondering if you could step in to moderate things again. We had gotten in an argument a few days ago because he had reverted one of edits on the park:type article. Then he accused me of being "autocratic" in the article and throw other insults at me. After that he edited and deleted a bunch of stuff I had written on the article. Which led to me attempting to discuss it on the on talk page. Which unfortunately led to more arguing on his side and me saying some things I probably shouldn't have. Although he has used a much a harsher tone and I took pains not to revert or modify his edits like he has done to me repeatedly. Yesterday I decided that it wasn't worth it anymore, sent him a message apologizing for the way I acted, and then decided to archive the none productive conversation like you had done the park talk page because I felt it would be a distraction to people that wanted to use the discussion page for actual conversation. Today he reverted the archiving I did and continued insulting me after I said I was done with it yesterday by saying me archiving the discussion was an attempt at censorship and he has continued to post personal, accusatory messages about me on the talk page. Last time I checked, I was under the impression that discussions can be archived for whatever reason and I don't feel that it is fair, or follows the rules, to revert someone based on their motivations for an edit. Although, it had nothing to do with trying to hide my comments. I probably should have reported him sooner, but I was a little bit worried about getting banned again. I don't want to edit war him either though and I'd like him to stop the harassing messages about me. Especially after I apologized and said I was done. Plus, I've had problem with him in other places anyway. So, id really appreciate it if you could step in again. Even if it means me getting banned a second time. It's better then continuing to be harassed by him for editing the wiki or getting my edits deleted for no reason. Thanks. --Adamant1 (talk) 09:17, 21 June 2019 (UTC)

maxweight example - MUTCD R12-5

Are you sure that MUTCD R12-5 is supposed to be maxaxleload=8 st?

Looking at it - it is showing two axle truck with 8 st limit, that would seem to be maxaxleload=4 st or maxweight:hgv=8 st Mateusz Konieczny (talk) 06:21, 23 June 2019 (UTC)

From looking at it seems to have nothing about axles (but I may be missing something) - "Posting of specific load limits may be accomplished by use of the Weight Limit symbol sign (R12-5). A sign containing the legend WEIGHT LIMIT on the top two lines, and showing three different truck symbols and their respective weight limits for which restrictions apply may be used, with the weight limits displayed to the right of each symbol as XX T. A bottom line of legend stating GROSS WT may be included if needed for enforcement purposes." Mateusz Konieczny (talk) 06:27, 23 June 2019 (UTC)

Key:maxbogieweight discussion page

Hey Minh Nguyễn, I answered to a change you made on the maxbogieweight wiki page in the associated talk page, would you have a look? --Westnordost (talk) 19:40, 25 June 2019 (UTC)

Edit of Common.css

The edit [1] just reformatted the license templates in a negative way like {{CC-BY-SA-4.0}} etc. Please reconsider! --Tigerfell This user is member of the wiki team of OSM (Let's talk) 17:57, 10 July 2019 (UTC)

@Tigerfell: Yikes, thanks for alerting me to the issue. The imbox rulesets are somewhat tangled up with other rulesets needed for navbox and {{Archives}} (which is why I had been mucking with the stylesheet in the first place). I updated {{CC-BY-SA-4.0}} to use {{Imbox}} based on the English Wikipedia version. It looks like there are a couple dozen other templates to update. Can we do that instead of rolling back the stylesheet changes? I think preexisting usage of {{Imbox}} would've been broken anyways. – Minh Nguyễn 💬 20:31, 10 July 2019 (UTC)
The archive search is also missing a template. --Andrew (talk) 21:14, 10 July 2019 (UTC)
(edit conflict) If you prefer to fix all of the templates, then go for it. Seems more difficult than changing just one. I do not know why those templates use the classes, I guess they were copied from WMF wikis. Why do you not test such changes at User:Minh Nguyen/common.css first? I doubt that there is some class sisterproject here.
When importing templates, please make sure you import the documentation as well. There are loads of undocumented templates already. Thx --Tigerfell This user is member of the wiki team of OSM (Let's talk) 21:24, 10 July 2019 (UTC)
@Wynndale: @Tigerfell: Sorry, I should've tested the changes first, though I assumed the imbox class was limited to {{Imbox}} – I probably wouldn't've caught the issues with hard-coded imbox classes without your help. I should've discussed the change beforehand, but it did look like an uncontroversial change given that it fixed {{Imbox}} and {{Archives}}. I'll adjust my definition of "uncontroversial" going forward. :^) (I brought over the latter template to clean up after a user who had archived a discussion without linking to it. Out of concern about people using archival without linking as a convenient way to hide discussions critical of their proposals, I tried to make it easier to archive properly.) Anyhow, I think I've fixed all the missing templates, and I copied over as little of the template documentation as possible. That's quite a rabbit hole in itself, because there are so many documentation-specific templates at Wikipedia; it makes little sense to maintain them all here. I'll get to the rest of the affected templates in a bit too. Thanks for your patience. – Minh Nguyễn 💬 00:10, 11 July 2019 (UTC)

UK National Cycle Network changes

Hi Minh,

I'm sure that the change at was meant well, but you can't just say "tag X is wrong, tag Y is correct" when tag X already has significant usage without noting that in the article. See e.g. the confusion at .

Also in this particular case the routes concerned actually extend beyond both GB (the island) and UKoGBaNI (the country) - I've personally seen signage for one in Ballyshannon, Ireland (in the Republic of Ireland). SomeoneElse (talk) 09:16, 18 July 2019 (UTC)

@SomeoneElse: I caught my mistake a few days after and meant to leave it at that. MacLondon edited the article back to GB: after changing the relations in OSM. I don't hold an opinion as to what it should be, though if UK: is to remain an exception compared to all the other cycle_network=* values, then it should be noted prominently on the wiki page and ideally the Ukrainian community should be aware of the exception too. – Minh Nguyễn 💬 16:52, 18 July 2019 (UTC)
There shouldn't really be any confusion regarding Ukraine, as the two-letter ISO country code for Ukraine is UA: according to --MacLondon (talk) 16:02, 22 July 2019 (UTC)
My bad, that's me confusing ISO country codes with ISO language codes again (uk for Ukranian). – Minh Nguyễn 💬 17:47, 22 July 2019 (UTC)

wikipedia links in tag definitions

Please do not add wikipedia links to tag definitions, they look as if the definition is found at wikipedia. They are also out of our control (can be modified according to different requirements and rules at any time even if they perfectly fit in this moment), and they make the definition incomplete (as external information in the link has to be looked at to get the complete picture). Add them as related concepts, e.g. in a See also-section. —Dieterdreist (talk) 13:58, 7 August 2019 (UTC)

@Dieterdreist: It's quite common to link to Wikipedia or use the {{Wikipedia}} template in the introductory section of a tag page on this wiki. I'd only link to a Wikipedia article if it's a good fit for what I'm trying to describe, and I try to capture the essence of the concept on this wiki. The link serves to tie OSM tags to real-world terminology when appropriate and also help users who don't speak English as a native language. If there's ever any conflict in usage, I'd prefer to make that contrast clear, in part by linking to Wikipedia. Do you have an example of where I've neglected to explain distinctions between OSM tags and Wikipedia definitions? – Minh Nguyễn 💬 18:30, 7 August 2019 (UTC)
Having a link (to wikipedia or another third party site, with or without template) is perfectly fine, but it should not be in the tag definition. I know it is still common, although I have been working to move these outside the definition in some cases, that’s why I wrote to you, hoping to raise awareness. There are also other mappers agreeing that the feature definitions should not be depending on external links.—Dieterdreist (talk) 21:27, 7 August 2019 (UTC)
I guess I don't really see how the links in pages like Tag:emergency=siren would cause us to be dependent on Wikipedia for definitions. The page itself defines the concept quite satisfactorily, in my opinion. The inline links to Wikipedia help readers understand tangential terminology like "horn" and "emergency alert". The "civil defense siren" link keeps us from digressing into minutiae that isn't as relevant to mapping. That's a particular concern of mine, because I've had to clean up several pages where a user clearly viewed this wiki as an opportunity to "geek out" about some hobby beyond what would be useful to mappers and data consumers. That said, I very much agree that we shouldn't use Wikipedia as a crutch to define concepts that are central to the tags and keys. For example, the same emergency=siren page used to link to Wikipedia with such a short definition that it practically forced the reader to consult Wikipedia for something more meaningful. – Minh Nguyễn 💬 09:05, 8 August 2019 (UTC)


Hi. Can you add the following code into MediaWiki:Common.css: .special li a[title="User:Dragomaniaca"]{font-weight:Bold;color:Blue}? Thanks! Flag of Brazil.svg Dragomaniaca Ping me here 23:03, 5 October 2019 (UTC)

<ignore>The OSM Wiki is not your private sandbox to mess around with. Please refrain from making further requests like these. Mmd (talk) 07:39, 6 October 2019 (UTC)</ignore>
NO!!!!!!!!! CAN I HAVE THIS CODE HERE: .special li a[title="User:Dragomaniaca"]{font-weight:Bold;color:Blue}? THANKS!!!!!!!!!!!!!! Flag of Brazil.svg Dragomaniaca Ping me here 18:13, 12 October 2019 (UTC)
Please stop making such requests. Especially in aggressive way, with CAPITAL letters and with exclamation marks. And especially as you make no productive edits anywhere on this wiki. Not sure whatever you noticed, but this is a Wiki to gather documentation supporting OpenStreetMap project. Mateusz Konieczny (talk) 21:45, 12 October 2019 (UTC)

Reviewing delete requests

Hi, could you have a look at the delete requests I filed some months ago. I could handle them myself, but that would defeat the purpose of the review process I guess. Most of the images listed were added by me. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 11:28, 21 December 2019 (UTC)

Maxspeed? --DaveF63 (talk) 14:10, 3 February 2020 (UTC)

OOjs UI icon check-constructive.svg Thanks for spotting the typo, DaveF63. – Minh Nguyễn 💬 20:34, 3 February 2020 (UTC)

Some bridges only allow a certain number of vehicles at a time

OK, but maybe "capacity" on a bridge=yes way is still not a good solution, at least it is not "common", because of almost a million capacity tags, only about 130 are with bridge=yes. Is the limitation about the whole bridge, or about one direction, or is the bridge oneway anyway? What if there is different maxspeed on the bridge (or any other property changes), you will split the highway with bridge=yes and capacity=10, and will get 2 such highways, i.e. a capacity of 20. IMHO the limit should either go on the man_made=bridge object (but then it would not be part of the highway, i.e. less probable available at routing time) or we need a relation, the bridge=yes ways are not suitable for holding such a limit because of the illustrated problem. If it is a restriction per direction, maybe a node could also do. I would also suggest a different word, like maxvehicles=* , but this is second. --Dieterdreist (talk) 16:17, 21 October 2020 (UTC)

@Dieterdreist: I added that bit to capacity=* in response to mapping a bridge with a "One Vehicle on Bridge at a Time" sign, which is nonstandard but not uncommon in the U.S. (The U.S. suffers from very poor coverage of bridges in general, so I wouldn't expect this combination to be common in OSM yet.) This bridge is indeed a one-lane bridge, and I'd expect such signs to be posted only at one-lane bridges; otherwise, there would be no point to accommodating more lanes of traffic.

I can see how splitting might pose a problem in theory, much like step_count=*; a more likely scenario is that the bridge spans a county boundary and both counties give the road a different name and number. I also agree that tagging man_made=bridge with the capacity is also useful. At the same time, a router might penalize a route that requires traversing a bridge with this restriction even more than it would normally penalize a one-lane bridge or tunnel. As you point out, man_made=bridge isn't relevant to routers, hence keys like maxheight=* and bridge:name=* being tagged very commonly on highway ways. I think some of the subkeys described on capacity=* make just as much sense for bridges as they do for parking lots. All this leads me to think something along the lines of an enforcement relation might be an appropriate way to address your concern about splitting, but I also hesitate to use an enforcement relation if there's no actual means of enforcement (other than the bridge collapsing). Do you have any suggestions?

 – Minh Nguyễn 💬 19:30, 21 October 2020 (UTC)

My suggestion would be to bring it up on the tagging list.—Dieterdreist (talk) 19:48, 21 October 2020 (UTC)

Enabling sticky headers on tables

Hi Minh, could you add a couple of CSS rules to enable sticky table headers? Rationale and more info here. Thank you! Dl3200 (talk) 05:02, 27 October 2020 (UTC)

See MediaWiki talk:Common.css.


Hi Minh

If you have lanes for both directions but different destinations and/or different turn-lanes or access restrictions you need destination:both_ways:forward/backward, turn:both_ways:forward/backward or access:both_ways:forward/backward. All can go with an additional :lanes in between, too.
You changes seem therefore not correct, cheers --Skyper (talk) 16:19, 6 January 2021 (UTC)

@Skyper: Just to be clear, both_ways=* means a single lane that handles traffic going in either direction at the same time, i.e., a center turn lane (also known in the U.S. as a "two-way left turn lane"). By contrast, if a road has forward and backward lanes and the forward lanes differ from the backward lanes, you'd tag that as turn:lanes:forward=* turn:lanes:backward=*, or turn:forward=* turn:backward=* if all the forward lanes and all the backward lanes have the same turn indication. For the simple reason of avoiding head-on or side collisions, it isn't possible for a center turn lane to have a different turn indication depending which direction you're traveling. If there is some center turn lane somewhere in the world that, say, allows cars going in either direction but trucks going only in the forward direction, that would be such a rarity that mentioning it as a representative example on Forward & backward, left & right would only add to the confusion for people unfamiliar with center turn lanes. – Minh Nguyễn 💬 19:04, 6 January 2021 (UTC)
@Minh Nguyen: Dear Minh, I was more concerned about your change comment than about the change on its own. I have seen more than only a single both_ways lane in reality, though. this is a rare situation. destination:both_ways=* might be a rare example but access=* and turn=* are by far rare. In fact, from my couch, the mentioned example in your change comment looks perfectly valid. There used to be many roads in France with a middle lane for overtaking for both directions at the same time but numbers dropped. At each end you have a turn:both_ways=merge_to_right but only in one direction. As for access, hgv=* is only one example but any vehicle=* or motor_vehicle=* are valid.
In the end, how about more words and more examples than deleting complicated examples with low numbers in data or reality. As author of the :lanes JOSM preset I would say I have some knowledge about subject but I remember, I added the example because myself was confused about the correct order and possibilities and I needed a place to document it. I should have added more words, though. --Skyper (talk) 15:28, 7 January 2021 (UTC)
@Skyper: Though I'm not intimately familiar with driving rules in Germany, I had thought the way I linked to in the edit summary corresponded to the traffic island in this Mapillary photo, hence my allegation that it was probably in error. But I didn't realize that it instead corresponded to the part of the roadway slightly beyond the traffic island. If so, I can understand how merge_to_right would rather uniquely be applicable to using the bidirectional lane in only one direction. To me, an edge case like this might warrant adding a footnote or at least prefacing it with a more common example of using both_ways according to the explanation given further up the page. Sorry for the confusion – though if you have ideas on how to also reduce confusion about center turn lanes, I think that would be a good improvement to the page as well. – Minh Nguyễn 💬 22:52, 7 January 2021 (UTC)
@Minh Nguyen: I tried to add some more information and more details about the complex examples, see [[2]]. --Skyper (talk) 14:54, 25 January 2021 (UTC)

flag:name - do you have some example of obscure flag actually displayed permanently? Something uploaded to Wikimedia Commons would be the best, ready to use. (I am going through User:Mateusz Konieczny/automatically generated list of various issues on OSM wiki and adding images to popular tags, in this case I have no idea for a good image). Or maybe just add random flag picture? Mateusz Konieczny (talk) 13:24, 23 March 2021 (UTC)

@Mateusz Konieczny: Thanks for the reminder. I added a photo of a flag that commemorates a single sporting event that would've flown for at least a year, if not longer. The fact that it appears in an image on Commons technically does qualify it to have a Wikidata item. I often rely on this key by itself when a non-notable apartment complex or factory has a flag bearing the company logo, but I think this championship flag is more self-explanatory. – Minh Nguyễn 💬 23:26, 23 March 2021 (UTC)

multivalue names, make sure which name is in which language

Hi Minh, it isn't actually possible with name:en or name:de to make clear which language the name is in. Take a look at London for example. Name is "London", but you cannot tell whether this is name:en, name:de, name:hu, name:jbo, name:ku etc. There was a proposal for an additional tag that would have stated which language(s) the name tag is in, but it was not established (AFAIK). We should reword the phrasing of key:name --Dieterdreist (talk) 21:27, 7 April 2021 (UTC)

@Dieterdreist: Yes, perhaps my wording was unfortunate. I only meant to say that, in cases like name=Берингов пролив / Bering Strait, it's helpful to also tag name:en=* and name:ru=*, not just name=* alone, so data consumers could know which language(s) uses which name. I think that's similar to what you were saying; I was just trying to simplify the wording a bit. – Minh Nguyễn 💬 22:13, 7 April 2021 (UTC)

Please modify the Wiki Translation url in zh-hant environment

Hi Minh, I am a Tradition Chinese native speaker and I'd notice that in my environment, the link "Wiki Translation" in the {{Language}} template is linking to a Simplified Chinese page Zh-hans:Wiki 翻译. I guess that is because of the magic word MediaWiki:Osm-wiki-translation-url/zh-hant. Please change the link into the Tradition Chinese link Zh-hant:Wiki翻譯, Thanks. --tntchn talk 14:58, 1 June 2021 (UTC)

@Tntchn: Done in 2160626. Thanks for noticing that! – Minh Nguyễn 💬 18:26, 1 June 2021 (UTC)

man_made=bridge definition

Hi, I believe man_made=bridge should include the "anchor" part of a bridge, i.e. the pylons should be included, towers should be included, etc. For bridge=yes on roads or railways, it makes sense to limit it like you described: "each end of the bridge should correspond to the point where the bridge's abutment ends and an opening begins below the bridge.", but for man_made=bridge, the whole "bridge" should be tagged, including structural parts beyond the opening. For example in this case you would want the pylons to be part of the bridge, no?

Suspension Bridge sepia.jpg

--Dieterdreist (talk) 22:52, 12 July 2021 (UTC)

@Dieterdreist: This is why I asked in Talk:Tag:man made=bridge#Extent of bridge. :^) The previous version of the article seemed to suggest that bridge:support=pier should be excluded from the bridge area. I don't have a strong opinion either way, but it would be helpful to add something explicit to each bridge-related page to avoid back-and-forth on the map. I've come across situations where the spans of a dual carriageway over a river are mapped completely differently. – Minh Nguyễn 💬 00:04, 13 July 2021 (UTC)
Thank you, will continue discussion on the talk page. --Dieterdreist (talk) 08:57, 13 July 2021 (UTC)

copy-paste vs link to reference

Re: [3] Thanks for clarifying the article. On a related note, I see you're active in "central" topics, so I'd share a word of experience - copy-paste disperses info across the wiki and, in the long run, helps make the wiki the mess of independently edited articles that it is today.

It should be trivial for newcomers to update a single article with rationale, corner cases, alternative schemes, ... without searching the wiki to copy-paste the updated details everywhere.

Newcomers should find a single reference linked everywhere (even if it is just a couple lines today) with maybe a vague, incomplete convenience tagging hint, not reference (to force the user to click the link at least once).

Keep up with the good work. Cheers --Pippo6 (talk) 11:21, 13 July 2021 (UTC)

@Pippo6: Thank you, I agree about avoiding significant copy-pasting. My intention with that edit was to make an existing cross-references more accurate. The previous wording unintentionally implied that service=emergency_access should be used for emergency ward entrances, whereas it said the opposite. If only one page is supposed to offer guidance on emergency ward entrance tagging, then I think it should be Tag:emergency=emergency_ward_entrance, not Tag:service=emergency_access. But maybe it's time for a dedicated Hospitals article that centralizes information about the various aspects of hospital mapping that a newcomer can discover. – Minh Nguyễn 💬 19:14, 13 July 2021 (UTC)
Hospital § " Mapping internal hospital structure" links specialized subpages/tags, but I do not see the current emergency access road info as hospital-specific. --Pippo6 (talk) 20:32, 13 July 2021 (UTC)


Thank you for the cleanning of the community=* pages. I had done several mistakes in naming : namespace, first cap... And I could not remove bad redirects. I don't know how to remove the mandatory religion=* in the description of the main page. If you know... FrViPofm (talk) 07:36, 23 August 2021 (UTC)

@FrViPofm: It came from the corresponding data item: this change removes the requirement from the infobox. – Minh Nguyễn 💬 08:11, 23 August 2021 (UTC)

Texas Historical Markers

Hello! There is a small group forming on Slack (#historical_markers) that are interested in clearly defining the proper tags. There are even a couple, like myself, from Texas that are very active in markers and contribute also to

Our recent conversations and research of tags on the wiki have convinced us that the proper tags are not tourism=information + information=board + board_type=history but rather historic=memorial + memorial=plaque

As an example: Texas_historical_marker_for_fort_Travis

Would be tagged as:

operator=Texas Historical Commmision
name=Fort Travis

With all this said - we are very interested in your opinion and feedback on this direction. I'd like to eventually update with examples.

Thanks! BubbleGuppies (talk) 04:20, 30 August 2021 (UTC)

@BubbleGuppies: I can see how board_type=history is suboptimal for this purpose, since these markers are commemorative. On the other hand, memorial=plaque has always been defined as being physically just a plaque mounted on a wall, boulder, "or other vertical surface", so renderers would naturally end up depicting them that way rather than as free-standing markers. (Compare this plaque and this marker in osm-carto and potentially other renderers.) I think it's incorrect for us to assume that a commemorative marker must be mounted on a wall as it would always be in Europe, but memorial=* is a mix of physical and functional values. So I support migrating existing usage over to memorial=plaque as long as we add support=post or marker=post to clarify the physical form of the marker. Otherwise, a new memorial=* value may be appropriate. For what it's worth, in Ohio, there are two similar-looking kinds of markers, both administered by Ohio History Connection: I'd support tagging the brown historical markers the same way as Texas Historical Markers but would probably keep the black Corporate Limit Markers as board_type=history, because they tend to be more like the first sentence of a Wikipedia article of a city, any city at all. – Minh Nguyễn 💬 05:37, 30 August 2021 (UTC)
By the way, I didn't write Texas/Map features#Official Texas Historical Markers; I just split it out from Special:PermanentLink/2108571#Texas Historical Commission, which had gotten unwieldy. – Minh Nguyễn 💬 05:45, 30 August 2021 (UTC)
Thanks for the feedback. I don't know if this is the most appropriate place, but if you don't mind, I'd like to continue the discussion as you seem to have experience.
The wikipedia page on plaques specifically uses historical markers as an example of a plaque. It also links to the THC markers as an example in the US. So - I've now convinced myself that these are more oppropriately defined as memorial plaques rather than information boards.
The next question I have is one that you mentioned in your response. How do we clarify if the plaque is free-standing versus mounted to a surface? The definition of plaque says it is "typically" mounted on a vertical surface but it is not necessary. Is the mounting not inferred from the location of the marker node? I mean, if the OSM node is attached to a way=building vs it's a node in the middle of a field. However, I am not opposed to adding some sort of "free-standing" key/tag.
I interpret marker=post to mean the post is the marker. I don't think that would be correct here.
support=* is better. But it may be a slippery slope. In the picture provided it's a wooden "post" but many more times the plaque is mounted on a metal "pole".
- BubbleGuppies (talk) 18:48, 30 August 2021 (UTC)
marker=post is already being used for highway=milestone where the location reference marker is a sign bolted onto the post. So the image for marker=post would be accurate but not quite representative of what it can be used for. But maybe I'm mistaken and marker=post is really only for what the wiki is documenting as is usage. My understanding is that, based on British English, support=post differs from support=pole based on its height, and the material doesn't matter – there's support:material=* for that – but either would work if you're able to tag height=*. – Minh Nguyễn 💬 19:18, 30 August 2021 (UTC)

Add code on common.css (.topbanner)

Hi Minh Nguyen, I would like to suggest adding a ".topbanner" to the common.css of the wiki to allow for a responsive image display (like on Wikipedia) :

.topbanner img {
    max-width: 100%;
    height: auto;

Could you add this on the common.css ?

Thanks in advance Koreller (talk) 21:26, 2 September 2021 (UTC)

@Koreller: I assume you're referring to the French Wikipedia's .topbanner class. (The English Wikipedia has a similarly-named class as part of the responsiveContent gadget, which I assume is for a different purpose.) Do you need just this .topbanner img rule or the entire set of rules under "Styles pour les bannières"? It would help to know what one of those banners looks like in a template, so we can make sure it doesn't conflict with any existing homegrown rules or ones that may have come from the English Wikipedia. – Minh Nguyễn 💬 21:33, 2 September 2021 (UTC)
Hello, yes I am referring to the template contained in the Wikipedia FR. The rule ".topbanner img" is sufficient for what I would like to do with it. I have created the template Template:Banner with a test in one of my subpages User:Koreller/Sandbox. Koreller (talk) 21:54, 2 September 2021 (UTC)
@Koreller: Done in Special:Diff/2194225 and Special:Diff/2194226 (since responsiveness is even more important on mobile devices). – Minh Nguyễn 💬 23:00, 2 September 2021 (UTC)
Thank a lot for this change, everything works fine ! Koreller (talk) 08:26, 3 September 2021 (UTC)

Querying trees

Hello! I just heard your presentation at WikidataCon, and I was happy that Sophox was up and running again! I have tried to query trees for a given taxon (like all the trees of a genre) but I can't get some trees that I know that exist, for example this: I don't know if I'm doing something wrong, or simply the data takes months to appear at Sophox.

SELECT ?tree ?taxon ?taxonLabel ?layer ?coordinates WHERE {
  # Query OpenStreetMap for trees and their taxa
  ?tree osmt:natural "tree";
        osmt:species:wikidata ?taxon;
        osmm:loc ?coordinates.
  # Query Wikidata for
    {?taxon wdt:P171 wd:Q190545.}
    # Get the Basque common name
      ?taxon wdt:P1843 ?taxonLabel.
      FILTER(LANG(?taxonLabel) = "eu")

Run it (edit query)

Thanks! -Theklan (talk) 22:04, 30 October 2021 (UTC)

@Theklan: Hi, thanks for attending the presentation! Unfortunately, I think you're seeing this serious regression that has affected Sophox since Yurik revived it on Google Cloud. (This is the issue I mentioned in the Q&A session afterwards.) It seems to affect nodes much more than ways or relations, probably because new nodes are added so much more frequently. In the meantime, for simpler queries like this, you could use the Overpass API to query for trees and their species:wikidata=* tags, export a list of the QIDs, then query the Wikidata Query Service for whatever is in that SERVICE block. It's quite inconvenient compared to using Sophox, but I don't know of a much better approach for queries for nodes. – Minh Nguyễn 💬 00:49, 31 October 2021 (UTC)

Traffic signs

Pages using the Traffic signs template render very slowly; at worst, Pl:Road signs in Poland doesn’t render at all. --Andrew (talk) 12:59, 26 March 2022 (UTC)

@Wynndale: Unfortunately, this is a known regression affecting any page with many images from Wikimedia Commons. Caching apparently doesn’t work on this wiki. For now, if a page fails to load, try visiting the page again right after it comes up blank. You should see the page contents along with any images that have been fetched so far. Minh Nguyễn 💬 16:37, 26 March 2022 (UTC)

Avoiding double redirects when moving pages

When moving pages it is usually beneficial to leave the option "Update any redirects that point to the original title" checked. The option avoids the creation of double redirects in most cases. As far as I can see, wikis run by Wikimedia do not have this option. Just wanted to let you know in case you did not. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 20:13, 21 April 2022 (UTC)

@Tigerfell: Thanks for the reminder! I thought I left it checked by default, but maybe not. – Minh Nguyễn 💬 21:08, 21 April 2022 (UTC)


note that new username set in is not existing either Mateusz Konieczny (talk) 16:59, 21 October 2022 (UTC)

traffic signals:countdown

I saw your change on traffic signals:countdown and I think that after the change the sentence is not longer "running nicely".

How about changing it to:

The count down is often not in seconds as traffic light installations are dynamic so if more or less other traffic comes, the time to wait can increase or

So change in the orignal text almost always to often.

Emvee (talk) 22:08, 16 November 2022 (UTC)

@Emvee: Done, thanks! – Minh Nguyễn 💬 22:44, 16 November 2022 (UTC)
I meant also to delete the "In some countries". I just changed the page to do so, please let me know if you do not agree. -- Emvee (talk) 22:04, 17 November 2022 (UTC)

data item statuslink

Hi! Just want to give the hint to set the statuslinks in data items as reference instead of qualifier. Chris --Chris2map (talk) 17:48, 1 July 2023 (UTC)

@Chris2map: Thanks for fixing that! I'm so reliant on Wikidata's constraint validator to catch mistakes like that... – Minh Nguyễn 💬 18:05, 1 July 2023 (UTC)
You're welcome! --Chris2map (talk) 18:09, 1 July 2023 (UTC)

Rtfm block

I know it's probably wrong to put conditions on someone being unblocked after the fact, but is any chance that you could request RTFM get rid of the insulting parts of his user page as a condition to being unblocked since part of the reason he was blocked was due to add hominem attacks and multiple people have asked him to change it in the past? Or alternatively can you just delete it? The "Arrogance comes from ignorance (assumed sabotage)" section is especially problematic IMO. Although the whole thing really just reads like a glorified attack page. So I don't think it should exist either way. Thanks. --Adamant1 (talk) 17:37, 29 July 2023 (UTC)

Babel template

Hello Minh Nguyen, every babel template user now sees a Please use {{#babel...}} notice but a #babel template does not exist - can you explain this? --katpatuka (talk) 06:50, 31 July 2023 (UTC)

@Katpatuka: This wiki has the Babel extension installed, which comes with a built-in replacement for {{Babel}}. #babel is a "magic word" rather than a template. To adopt it, you can replace {{babel|de|en-3|tr-2}} with {{#babel:de|en-3|tr-2}}. The warning came over when I updated {{Babel}} to match the latest version on Wikimedia wikis. The magic word works much more reliably than the old version of the template, since we don't have to maintain any templates or categories for individual levels of language codes. It also affects some settings on the wiki, such as the languages for labels on data item pages. However, the new version of the template is already using the magic word under the hood, so I'm not sure why the template is a problem, other than some indirection. Special:Diff/2579149 removes the warning, so you don't have to upgrade if you don't want to. – Minh Nguyễn 💬 08:23, 31 July 2023 (UTC)
I see - I had tested the #babel version but still saw a notice which you've now fixed with your latest edit;) --katpatuka (talk) 08:49, 31 July 2023 (UTC)

Data Item Duplication

Hello! It seems to me that Item:Q22076 is a duplicate of Item:Q247 not sure if should be merged, deleted or changed in a "key prefix" to represent Key:drink:* -- Ernsterwinwg (talk) 16:58, 11 August 2023‎ (UTC)

@Ernsterwinwg: Hi, currently, drink (Q22076) represents the key drink=*, while drink (Q247) represents the key prefix drink:*=*. Both are currently in use in the OSM database, and both syntaxes are documented, albeit in a different set of languages. This is unfortunate, but the separate data items probably should remain until the inconsistency is resolved elsewhere. In the meantime, I've linked drink (Q22076) to drink (Q247) so data consumers can potentially discover the two keys. – Minh Nguyễn 💬 19:14, 11 August 2023 (UTC)
Thanks for your reply and for your edits! So before your edits drink (Q247) had the statement "instance of : key" as well? that was confusing me, now it makes total sense.I arrived to that iteam from this discussion, do you think it make sense do do a systematic cleaning (according to some specifications)of key prefixes and suffixes in the "Item" Namespace? -- Ernsterwinwg (talk) 09:39, 12 August 2023 (UTC)

@Ernsterwinwg: Yes, drink (Q247) originally was an instance of a key, even though some language versions of the page had been rewritten to discuss a prefix instead. There does need to be a more thorough cleanup of key prefix and suffix data items. The relevant properties were only created a couple months ago, well after people started moving the pages to match the approved proposal. It’s a bit time-consuming to figure out the situation for each key, but fortunately fixing the data item is pretty straightforward. I recommend temporarily disabling the “Show values of statements in data items as links and thumbnail images” gadget in your gadget preferences so you can easily delete the permanent key ID (P16) statement in favor of a new permanent key prefix ID (P52) statement. Minh Nguyễn 💬 15:04, 12 August 2023 (UTC)

Thanks for your reply and for the tip about the gadget preference. I also am wondering if there is already a tool to add (show) in a wikipage (in the namespace Key: or Tag:) a link the corresponding Item: page.
This also in order to quickly check if the respective Data Item already exist or not. I saw there was some work to add this functionality in the respective wiki templates but as far I understand is not there yet. Ernsterwinwg (talk) 15:28, 27 August 2023 (UTC)
@Ernsterwinwg: If there’s a sitelink from a data item to an article, the article will have a Data item link in the sidebar. – Minh Nguyễn 💬 16:32, 27 August 2023 (UTC)
Thanks, very convenient, sorry I was not yet aware of this. Ernsterwinwg (talk) 06:02, 28 August 2023 (UTC)

Add code on common.css (.topbanner .name)

Hi Minh Nguyen, I would like to suggest adding a ".topbanner .name" to the common.css (MediaWiki:Common.css) of this wiki to allow to put a namepage on a banner (like on french Wikipedia for this render :

.topbanner .name {
	position: absolute;
	z-index: 2;
	margin: 0.6em 0 0 0.4em;
	padding: 8px 7px;
	font-size: 2.2em;
	background: rgb(16,16,16);
	background: rgba(0,0,0,0.5);
	border-radius: 4px;
	color: white;
	white-space: nowrap;
	line-height: 0.9em;

Could you add this on the common.css ?

Thanks in advance — Koreller (talk) 08:03, 14 October 2023 (UTC)

@Koreller: Can a template include some CSS for the same effect? Or is the issue that the background properties get sanitized? By the way, in my opinion, a map masthead can be even more interesting than the clip art banners from the French Wikipedia or Wikivoyage. For example, Ohio features a daily rotating interactive map of well-mapped or well-known places in Ohio, powered by Module:CarouselMap (via {{Ohio/Map}}) and {{Ohio/Masthead}}. – Minh Nguyễn 💬 00:30, 17 October 2023 (UTC)
So I did the edit on the template, but as you can see here (see the wikicode also) this doesn't work... so I think it should be edit on the commons.css. Or can you try to make it work ? (is it even possible?)
Or course more choice of template is a really good think and that way everyone can do what they think is most relevant! — Koreller (talk) 17:02, 17 October 2023 (UTC)
Thanks @Chris2map for your change, it work now ! — Koreller (talk) 19:27, 18 October 2023 (UTC)

File in proposal

Is it fine to remove use of in together with associated example?

Sadly source and license of that file is not 100% certain.

If it special in some way - what would be needed from replacement?

Mateusz Konieczny (talk) 17:01, 3 November 2023 (UTC)

@Mateusz Konieczny: I replaced every use of this image with File:2019-06-14 16 32 35 View southeast along the Outer Loop of the Baltimore Beltway (Interstate 695) at Exit 7B (Maryland State Route 295 NORTH-Baltimore-Washington Parkway, Baltimore) in Linthicum, Anne Arundel County, Maryland.jpg. Duane is still involved with the project if you want to ask him for more information anyways. – Minh Nguyễn 💬 18:50, 3 November 2023 (UTC)

SPARQL section SPARQL_pages

Hello, I saw some old TODO tasks listed at SPARQL#SPARQL_pages. The tasks appear to be solved and I was thinking about deleting the section. I see that you've moved pages and fixed categories (thank you!) so I thought to double-check by asking you. --Opk12 (talk) 21:16, 22 February 2024 (UTC)

@Opk12: Yes, we can remove the section, thank you. The new QLever/Example queries page is still quite incomplete compared to Sophox/Example queries. I just haven't had time to port them over yet. A bunch of them won't translate cleanly, because Sophox has more visualization capabilities, while QLever has more powerful geometry capabilities. – Minh Nguyễn 💬 01:13, 23 February 2024 (UTC)