User talk:Kovposch

What is questioned, contended or controversial?

Which part of page at https://wiki.openstreetmap.org/w/index.php?title=Key:industrial&curid=90150&diff=2007524&oldid=2007287 is questioned, contended or controversial and not easily fixable and required adding the template? Mateusz Konieczny (talk) 17:01, 2 July 2020 (UTC)

I see someone has added "Please have a look at discussion on talk page." on a few of the individual values, but I don't know how should I edit the entire section to reflect all the doubts raised in the talk page. Since its purpose is to record existing values in very limited use only, I don't think it would be helpful to remove them directly. -- Kovposch (talk) 10:02, 4 July 2020 (UTC)

Your edits on default speed limits

Please read the contribution guidelines further below in the article before editing the page. Scanning over your edits, it looks like all of them must be reverted. --Westnordost (talk) 11:31, 25 July 2022 (UTC)

Yes, I'm correcting them. Kovposch (talk) 11:34, 25 July 2022 (UTC)

How to represent the speed limit cut-off of other vehicles that applies when there is a higher signposted speed limit? It's not about "motorway". --- Kovposch (talk) 11:52, 25 July 2022 (UTC)

It is not possible yet, but I plan to re-write the document so that ALL speed limits except the default speed limits are to be interpreted as cut-off. In other words, for any road, for example "default speed=50 + hgv speed=60 + speed for vehicles with mgv > 3.5t = 60" will mean that HGV and other vehicles with MGV > 3.5t may also only go 50 km/h and if a higher speed limit is signed, not faster than 60 km/h --Westnordost (talk) 11:59, 25 July 2022 (UTC)

So should I do this first, add a new classification with eg maxspeed > 70, note in the article or discussion, or let you handle it? --- Kovposch (talk) 12:10, 25 July 2022 (UTC)

I will need to go from A-Z in this table anyway, I think it is less confusing if this was not changed in the table right now for singular countries (as the table currently tries to not have any HGV, ...etc seem to have a higher speed than default) --Westnordost (talk) 12:21, 25 July 2022 (UTC)

Your edits on default speed limits (2)

Thank you for your correction. I've reviewed and compared it to the road traffic ordinance linked and indeed, I don't know where I got the previous values from (100 on motorway etc.), they are not mentioned at all --Westnordost (talk) 13:52, 25 July 2022 (UTC)

street parking revision

Hey Kovposch, the proposal for the street parking revision is almost getting ready... Since some of the content was inspired by your "Counter Proposal" from last year: Should/can I write something like "partly based on a proposal by Kovposch" in the authors' list?

I don't know if you have followed the developing of the proposal in the last couple of days - maybe you have some more comments. We may start the RFC soon. --Supaplex030 (talk) 21:03, 1 November 2022 (UTC)

Thanks. That's great. I don't have much to say about markings. Let me take a look again. --- Kovposch (talk) 02:44, 2 November 2022 (UTC)

Your edits on default speed limits (3)

In your recent edit, you added a lot of whitespace changes. I suspect the UI editor is to blame. Regardless, this makes it hard to review.

Anyway, you claim to have corrected a syntax error / improve the syntax for Hong Kong in the change comment, but what you actually did was to delete information alongside the previously carefully researched references (and break a link to wikipedia). There was no syntax error. I reverted these, please be more careful in the future. If there is actually something wrong, please always cite the source in a ref link as described in the contribution guidelines. If unsure, rather add a topic on the discussion page. --Westnordost (talk) 10:20, 20 April 2023 (UTC)

I misunderstood the syntax in the first place. The 19 seats and 5.5t are vehicle class definition, not speed limits definitions. As a result, the cited laws are not relevant to the speed limits. Kovposch (talk) 13:45, 20 April 2023 (UTC)

They are relevant. The speed limit definitions refer to vehicle classes. Hence, the references to vehicle class definitions are included. E.g. if a higher speed limit applies through signage, medium goods vehicles, heavy goods vehicles and buses may still not go faster than 70 km/h. At which gross vehicle weight a goods vehicle is classified as a "medium goods vehicle" is thus relevant. (etc) --Westnordost (talk) 14:40, 20 April 2023 (UTC)

Ok I will modify accordingly, --- Kovposch (talk) 15:56, 20 April 2023 (UTC)

No need, I already reverted that change (and checked the legislation text. Everything seems to be in order) --Westnordost (talk) 15:58, 20 April 2023 (UTC)

The 19 seats and 5.5t are defined for the vehicle class. They should not be used as the condition.
And minibus=* is <= 19 seats, not >=19 as explained in Default_speed_limits#Meaning of values in cells. So this redundant syntax doesn't work in any case.
--- --- Kovposch (talk) 16:00, 20 April 2023 (UTC)

Yes, they should be in the definition because the default assumed gross vehicle weight of a HGV is 3.5t, not 5.5t. In Hong Kong, no speed limit other than the one signed applies to you if you drive at truck with gross vehicle weight 3.5t. Regarding the note about the 19 seats, right, the default assumed seats for minibuses seems to be about 12, so actually there should be a second row for the buses column. `70, 80 (19 seats)`. --Westnordost (talk) 16:05, 20 April 2023 (UTC)

Then either your syntax or documentation is wrong because 80 (19 seats) is supposed to be interpreted as >=19 seats, not <=19 seats. --- Kovposch (talk) 16:09, 20 April 2023 (UTC)

Right, correct. So the bus column must be changed to `80, 70 (19 seats)` --Westnordost (talk) 16:11, 20 April 2023 (UTC)

Done and let's discuss anything else there. --- Kovposch (talk) 16:23, 20 April 2023 (UTC)

Talk:key:lit

Please stop derailing the discussion into rhetoric, it's rude and makes it hard for others to follow. If you still have a genuine problem with luminous after I explained twice, you'll need to ask elsewhere, that section is not the right place. --Opk12 (talk) 07:38, 21 June 2023 (UTC)

Says the one who deletes other's comments after being pointed out how the content's point is also off-topic. --- Kovposch (talk) 08:35, 21 June 2023 (UTC)

Please calm down and ask the community to explain luminous to you. The issue is how to tag the bench, I don't care about the light source, you can't put luminous on a bench.

• Key:luminous - "is emitting light". Neon example at the right. This is also the meaning in English language.
• Key:advertising - "lit=* - indicates if the advertising device is lit." "luminous=* - indicates if the advertising device is luminous, i.e. if it emits some light."

For clarity, the meaning of the English word emit does not include reflecting light.

--Opk12 (talk) 15:47, 21 June 2023 (UTC)

You are hiding and deleting other's comments. So why don't you stop with that? Referring to Wiki, "Involved parties must not use these templates to end a discussion over the objections of other editors.". And I'm not making "personal commentary" between us. "normally you should stop if there is any objection". https://en.wikipedia.org/wiki/Wikipedia:Talk_page_guidelines#Editing_others'_comments
I provided various examples of illuminated benches for comparison. By the same logic, is it that a backlit board doesn't qualify, because the cover itself doesn't emit light? OSM doesn't necessarily follow English meaning. I'm explaining the limitation in these definitions. light_source=* is a better choice for at least neon lights.
--- Kovposch (talk) 05:43, 22 June 2023 (UTC)

To the extreme, you do know there are many upward lamp street lights with top reflectors? Are they not emitting light? --- Kovposch (talk) 06:07, 22 June 2023 (UTC)

You're wasting your time arguing "lights inside = luminous", you misunderstood the topic "has light infrastructure", it means "there is light targeted at it from a designated object" (I did not mentioned where, could be inside, attached but not inside, nearby) this topic has nothing to do with "how to tag lights inside a bench". Even if lights are inside, that either is usually lit=no or does not change lit (as in your photos), because there aren't reflective surfaces around (including for traffic safety reasons), so light does not get back at the bench.

You are hijacking a concrete proposal to split a key, with unrelated newbie Qs "what if I find a grey area and common sense won't help" (kindly ask the chat or community forum; step back on an unknown subject) and "how to tag a bench with a light" (2 OSM features, as they functionally count as two). Legitimate Qs, but mapper's practice counts more. --Opk12 (talk) 10:35, 24 June 2023 (UTC)

You yourself have clarified you want to talk about ""has possibly ineffective lights" after asking to "keep this section focused". Your question title is "light is installed", so I answered luminous=* and light_source=* if it is on it. You claimed "your example is lit and not luminous", so I explained the cases that needs to be considered. Since you "did not mentioned where, could be inside, attached but not inside, nearby", being attached to the bench is an obvious, straightforward, non-subjective case to consider, which is a possibility that's not "has nothing to do". You can also still use light_source=* on the same point for convenience even if it is slightly spaced at first, only separating into 2 features later on. It can be difficult to determine when is it is dedicated. Benches can be placed near light poles along a footpath. What does this order entails?
You are ignoring Wikipedia-based guidelines on deleting other's comments. I'm not asking. I'm elaborating on how this question has more than you think. This is a wiki discussion, not a help question.
--- Kovposch (talk) 06:56, 25 June 2023 (UTC)

Map user

May I ask for your mapper username to better understand your mapping experience? Fernando Trebien (talk) 18:37, 5 October 2023 (UTC)

Why delete your own comment?

Can you explain why you did this? Without explanation, I find it looks very strange to delete user contributions from a discussion page, even your own. --Martianfreeloader (talk) 22:17, 6 February 2024 (UTC)

It's off-topic. I misunderstood the question.
—— Kovposch (talk) 23:21, 6 February 2024 (UTC)

Convenient Discussion is too "convenient"
—— Kovposch (talk) 23:24, 6 February 2024 (UTC)

Double "parking"

@Mueschel: Per last in https://www.openstreetmap.org/changeset/152425486 :

1. I'm using *:lanes=* as I documented my own restriction=no_blocking for box junctions, and restriction:advisory=no_blocking for informatory "keep clear" text at driveways. The existing {{tag|restriction:This isn't limited to the intersection conflict area.
   1. File:HK 半山區 Mid-levels 醫院道 Hospital Road February 2020 SS2 01.jpg : Very long yellow box at the approach to accommodate the tight left turn on the oblique-angled intersection
   2. File:HK_Canal_Road_Flyover.jpg : 2 lanes on the left marked as a 2-car-length yellow box for weaving inside the queue back from the off-slip, not on the entire roadway or the sides only
2. width:carriageway=* currently describes its use of "carriageway" as kerb-to-kerb including parking, both parking=lane and possibly parking=street_side . That needs to be changed. Even then, parking=lane is still described as part of the "carriageway". In Tag:parking=street_side#Distinction_between_street_side_and_lane_parking , it is described as a part of the "carriageway" which can be easily restored to traffic without major altercations. So "carriageway" doesn't re

Originally during the revamp proposal discussion. I thought about suggesting parking:side:lane and parking:side:street_side etc, as an alternative to keeping parking:lane:*=* to avoid suffixing parking=* directly. This would allow different stopping locations to co-exist. But it seemed unnecessary to tackle in one go, when deprecating parking:lane:*=* is more important.
—— Kovposch (talk) 10:28, 10 June 2024 (UTC)

So you can make a vote (flipped the LHT locally for readability in the RHT world ) :

• Conflicting parking:right=separate + parking:right:restriction=no_stopping (because this parking:right:restriction=no_stopping doesn't refer to the parking:left=separate )
• parking:restriction:lanes:forward=* (LHT)
• New infix
• parking:restriction:conditional=*
• Other possibility we can think of
• Others

—— Kovposch (talk) 10:41, 10 June 2024 (UTC)

Format-wise, this reminds me of Sidewalks#As_a_pedestrian_lane_on_the_road . There is an extra difficultly, the same as here, when there is a pedestrian lane in addition to a sidewalk.

• https://img.ltn.com.tw/Upload/news/600/2012/04/28/143.jpg https://news.ltn.com.tw/news/local/paper/579606

—— Kovposch (talk) 10:53, 10 June 2024 (UTC)

Some remarks

parking:restriction:lanes:forward

From a linguistic point of view, the tag makes sense - but it doesn't really fit with other tags.

My main concern is that this looks like the :lanes suffix, but it is not: It refers to the position "on the lanes", but not to a property that is different on each lane. How would the tag look like on a two-lane road? If it has no two values, every QA tool will start to complain that the number of lanes doesn't match between tags. And vice versa, if there is only one value, then the ':lanes' suffix can be dropped for every other tag, but not in this case. This might lead to a lot of confusion.

And lastly, this scheme might be able to solve the "HK double yellow line" problem, but there are other cases where a secondary parking restriction exists, but is not related to lanes. --Mueschel (talk) 18:30, 10 June 2024 (UTC)

parking:right:[lane|street_side|on_kerb]:restriction

This would be the most versatile tagging scheme, but also adds a lot of complexity. One of the main concerns of the updated scheme was to keep values out of the key, and this would negate this improvement. Apart from that, it seems like a good solution. I currently know of no restrictions that can't be handled by this - if there are, they are rare. --Mueschel (talk) 18:30, 10 June 2024 (UTC)

parking:right:restriction:conditional= no_stopping @ parking=lane Using a conditional tag has several advantages: First, it keeps the key clean. ':conditional' is something that all interpreters must support for parking given the amount of conditional restrictions we have. Depending on the point of view, you might argue that this is not a condition. My opinion is that it is a condition - the condition is the place where the parking is supposed to happen. There's no problem if the object as a non-conditional 'parking:right:restriction' at the same time - this, by definition, describes parking in the location given in the main 'parking' tag. The conditional tag just adds on it by giving another restriction in another location. --Mueschel (talk) 18:30, 10 June 2024 (UTC)

• parking:restriction:lanes=* : I mainly used it for yellow boxes. They can be ignored for this topic. But I do intend to use RHT parking:restriction:lanes:forward=none|no_stopping + parking:restriction:lanes:backward=none|no_stopping for lanes=4 + oneway=no . There is still turn:lanes:both_ways=* dominant over turn:both_ways=* when basically all cases should be a single two-way turn lane. Others appear to be mistakes, from the few I glanced through.
• parking:*:lane:restriction=* : Yes, I do prefer it. However, adding an infix may affect the interpretation now. I thought parking:restriction:lanes=* avoid any effects on them. For comparison, RHT busway:right=lane won't express there is a bus left-turn lane on a oneway=no . That requires bus:lanes=* .
• parking:*:restriction:conditional=* : My argument is first, it doesn't refer to the same parking:*=street_side as parking:*:restriction=* should be. So it's a deviation from what parking:*:restriction=* should describe. In the German post where you suggested parking:right:restriction:conditional=no_parking @ (unmarked) , it is still referring to what's happening on the same parking:*=lane .

—— Kovposch (talk) 09:20, 11 June 2024 (UTC)

Marked restriction on traffic lane outside a parking bay

Option	For	Against
parking:right=separate parking:restriction:lanes:forward=none|no_stopping	sdfdfs	parking:restriction=* doesn't conform to parking:right=* , restriction=* (on amenity=parking ) Deviates from *:lanes=* specification Appears to change meaning of parking:*=* The parking:right=separate is not considered in parking:restriction:lanes:forward=* parking:restriction:lanes:forward=no_stopping can't be simplified into parking:restriction:forward=no_stopping Not useful to specify multiple lanes in almost all cases More effort to enter on multi-lane roads May be more error-prone
parking:right=separate parking:right:lane:restriction=no_stopping / parking:right:carriageway:restriction=no_stopping ?	sdfdfssdf	Reintroduces parking=* vals in parking:right:*=* Deviates from proposal specification Complicates parking:right:*=* syntax May be confused with deprecated parking:lane:right=* For the meaning of *:carriageway=* from width:carriageway=* Documentation includes parking:lane=* "kerb-to-kerb" definition would further include parking=street_side
parking:right=separate parking:right:restriction=no_stopping	dsadassadas	May be misunderstood as editing mistake The parking:right:*=* refers to something that's not for the parking:right=separate Adds parking:right:*=* attributes that a parking:right=separate is supposed to be free of, as they should be moved to the amenity=parking parking:right=separate may cause applications to not further interpret the parking:right:restriction=*
parking:right=separate parking:right:restriction:conditionalno_stopping @ parking=lane	dfsdfsfds	parking=lane looks more of a location than condition. Elsewhere, sidewalk:right:bicycle=* is used, not bicycle:conditional=* The parking:right:*=* refers to something that's not for the parking:right=separate Adds parking:right:*=* attributes that a parking:right=separate is supposed to be free of, as they should be moved to the amenity=parking parking:right=separate may cause applications to not further interpret the parking:right:restriction=*

—— Kovposch (talk) 17:31, 11 June 2024 (UTC)

+1 Nice summary. A lot of possible disadvantages with any of the options. I'm currently not decided what the best solution might look like... --Mueschel (talk) 18:02, 11 June 2024 (UTC)

Mentioned this in the local Discord community in case anyone has some comments. I will wait and see.
—— Kovposch (talk) 13:37, 12 June 2024 (UTC)