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)

Yes check.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)

Yes check.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)