I find bikelanes that are integrated with sidewalks incredibly dangerous and give a false sense of safety. Bikes hitting pedestrians (ex: children wandering out on to the bikelane) is a much larger safety concern than bikes being hit by cars. Taipei uses the sidewalk model and I recommend never using them
I find the Chinese model of bike/scooter lanes w/ barriers integrated into the main road a superior model. The other critical point is integrating bus stops into "islands" in the road so the bike lanes go behind the bus stops is critical. (a stopped bus with passengers going on/off essentially closes off the shoulder for an extended amount of time). Granted the main roads in Chinese cities are generally much wider so I'm not sure if it can be miniaturized the same way. The "turning area" is very useful concept for unblocking traffic and helping with visibility, though it does take up a lot of space. However the one in the example only accommodates one turning car at a time
1199 cyclists killed in 4 years, 658 of these being from collisions with various motor vehicles. 262 pedestrians killed in 4 years, 11 of these being from collisions with bicycles. Before any "oh but there's few deaths but more accidents it's still unsafe": no, it is not.
I know your username sets high expectations, but stop bullshitting and look at facts.
If a bicycle hits a pedestrian and the pedestrian was on cycling path in The Netherlands, who's fault is it? If the pedestrian gets a broken arm who pays for medical services?
If NL laws are anywhere close to the rest of European countries: the bike is responsible. The pedestrian is never responsible, unless they do something absurd like jumping in front of the bike without leaving any way to react to the bike.
>If the pedestrian gets a broken arm who pays for medical services?
The... Insurance of whoever is responsible? I know this concept is weird to the US, but personal insurances in Europe are about covering the damage you inflict on others first, then eventually you. They're also mandatory. In addition, well, a broken arm is not a financial catastrophe in Europe. Should it prevent you from doing your job, the insurance also covers that.
I broadly agree that I'd like standalone separated bike lanes, but I think this is dubious:
> Bikes hitting pedestrians (ex: children wandering out on to the bikelane) is a much larger safety concern than bikes being hit by cars
As far as I'm aware, more or less everywhere, both the frequency & severity of bicycle vs pedestrian crashes is much lower than bicycle vs car crashes. Do you have any statistics that say otherwise?
I only have my personal experience. Biking on the sidewalk lanes in Taipei creates a lot of scary close calls esp with children and dogs. On the road I only rarely have some issues with buses. Everyone is moving in the same direction so it's generally less scary.
I think in terms of deaths, the most dangerous issue is getting t-boned at an intersection by a car going fast through the intersection. I'm not sure how either setup really addresses that. You need to decrease overall traffic speed somehow. Chinese do this with speed cameras everywhere and electric scooters being much slower than gas powered ones (which are illegal most places now)
> I find bikelanes that are integrated with sidewalks incredibly dangerous and give a false sense of safety.
As a cyclist, I also hate them. In my experience, what is even more dangerous than small children is dogs. Even if they are on a leash, there is nothing stopping them from just suddenly jumping a meter to the left, right in front of your bike.
The dreaded multi-use path where pedestrians, joggers, dog walkers, parents with strollers, bike commuters, e-scooters, roadies, kids with training wheels and older folks on 4 wheel scooters are forced to share the same 2.5m strip of asphalt, while cars get 2 lanes to drive and 2 for storage
Not sure if you mean the Dutch style cycle lanes: in that case, it's just tourists that risk impact with bikes, simply because they're conditioned to ignore them (i.e. the brain is trained to consider dangerous only what's beyond the curb).
After a few weeks people just learn to be mindful of bicycles and bicycle lanes as they are normally mindful of roads. In particular, one learns to never change direction suddenly (crossing a bike lane, but also on a shared road) but to stop first and check behind their back for potential cyclists.
I guess this conditioning just doesn't happen in Taipei .. I guess then I don't really understand why the sidewalk and bikelane are on the same level at all. Why not have an actual barrier or curb and places to get on/off?
it's effectively another road - with the same dangers as a car-road. But it's just some painted asphalt
Being used to Dutch bike infrastructure, the bike lanes in Taipei made no sense to me. The ones I've seen mostly are barely distinguishable from the actual sidewalk and at large intersections the "bike lanes" seem to overlap with the logical/natural spot for pedestrians to wait for a green light.
> Why not have an actual barrier or curb and places to get on/off?
There actually commonly is a barrier; a gentle curve between the foot path and bike path, with the bike path being lower. The bike path is also red asphalt making it visually distinct.
> Bikes hitting pedestrians is a much larger safety concern than bikes being hit by cars.
Do you have any empirical evidence for this? Because every single study I have seen suggest that speed and weight of the participants matters most. And a bike and a person are simply, much less likely to cause serious harm.
A car can kill a biker easy, for a bike to kill anybody, you need to really be incredibly unlucky.
The Dutch are doing a lot of empirical work, and they have not adopted anything like you describe.
I think if you tried them out you'll find these bike paths are not unsafe (and I bet the accident numbers back that up), because it's a whole system. Design like this will have features to force drivers to take slow turns when crossing the bike paths, and they are raised so that it's clear to drivers they don't have right of way.
NL always goes for the transit stops that poke out like you mention as well when possible.
When we visited Amsterdam as pedestrians, we absolutely hated these bike lane / sidewalk combinations. The problem are the often narrow, obstructed sidewalks forcing you to step into the bike lane. I wouldn't call that "incredibly dangerous" though, after all, we didn't witness any accident, but certainly annoying, especially considering that the most common obstruction is parked bikes.
I guess it takes some getting used to, or maybe the Dutch simply avoid walking and take the bike instead.
"Bikes hitting pedestrians (ex: children wandering out on to the bikelane) is a much larger safety concern than bikes being hit by cars."
what? there are many orders of magnitude more injuries and deaths from bikes being hit by cars than there are from pedestrians being hit by bikes. Even when a pedestrian is hit (which is rare- both are highly nimble), it is very rare that it is problematic because a bike carries so little momentum
> Bikes hitting pedestrians (ex: children wandering out on to the bikelane) is a much larger safety concern than bikes being hit by cars.
That's blatantly not true. Have you seen any KSI statistics?
Pedestrians are more likely to be killed by a driver mounting the pavement and hitting them than they are by a cyclist. The facts suggest that in a cyclist/pedestrian collision, it's often the cyclist that gets more injured.
It's a bit unclear to me why you need an organization that advocates against nuclear weapons. I'd argue the “nuclear taboo” is just the product of.. I don't just seeing one nuclear test video? It doesn't take the cataloging of witness testimony to see it's terror (though that may be important in its own right)
I'm not intimately familiar with Japanese self-perceptions - but from the outside it seems like post-WW2 the country really leaned into a view that "nuclear weapons are terrible" to the point of distraction - instead of a more self-reflective "nationalism is terrible" or something along those lines. There seems to be much less anxiety about preventing getting into a similar situations that triggered WW2: neo-colonial military bullying and domination of neighbors, xenaphobic oppression of ethnic groups, sycophantic following of cultural leaders etc. and an intense worry about the more tangeable use of nuclear weapons - which I'd argue is something that even if it were to come to pass would almost certainly never involve the Japanese people.
I wonder how this seeming diversion of public attention is perceived in Japan itself.
As I understand it, the anti-nationalist narrative was repressed due to anti-communist agendas of the occupation forces (ex: freeing of nationalist war criminals)
Would be curious to hear from anyone Japanese on the topic
The general human tendency to focus on single short term events seems to be the main cause.
Let's compare using Wikipedia as a source:
Atomic bombings in Japan:
50,000–246,000 casualties.
Air Raids in Japan:
241,000–900,000 killed,
213,000–1,300,000 wounded,
8,500,000 rendered homeless.
Mass killings of large civilian populations should not happen. I don't personally see nuclear weapons as worse than incendiary bombs or artillery. It's the number of casualties that makes it horrible.
* one early bomb is more or less equivilant to one conventional HE + incendiary raid.
* 2,000+ other bombs have since been detonated, a good number of which were orders of magnitudes more destructive than the early "first gen" bombs used on Japan.
Nuclear war with the larger weapons that followed would be considerably worse than incendiary bombs, in physical destruction, in immediate deaths, and in injuries and following mortalities.
I agree. I've been to the Hiroshima Peace Park or whatever it's called in English numerous times, but I can't say I've been anymore moved by it than any other demonstration of human brutality.
I can't register a difference between a nuclear bomb and, say, a GBU-12 Paveway conventional bomb. They both destroy and kill brutally, the magnitude is irrelevant and it would be great if we never have to use either of them.
I'm Japanese-American, so I can throw two cents in your hat.
Post-war Japan is against nuclear weapons to an absolute, but it must be admitted that the response to nukes in particular is just as much a kneejerk reaction. NHK literally spams the entirety of August with anti-nuclear propaganda every year. Japan's anti-nuclear stance is also hypocritically at odds with relying on the US nuclear umbrella for national security.
More rationally, post-war Japan is against wars of any and all kinds to an absolute. This goes as far as refusing to defend the US in the event of an attack on the US-Japan alliance; this was only changed recently in the last decade or so after strong pressure from the US to reciprocate the US's defense commitments to Japan.
Nationalism is a... complex topic. You will be considered a crazy person if you wave the Japanese flag or put up a flagpole on or around your house, but at the same time loyalty and reverence to the Emperor still remains strong and the country is politically and culturally very conservative/liberal with a very interesting mix of individualism and conformity. Most Japanese ex-pats actually leave Japan because they are more progressive and can't stand the conservative culture.
Japan is actually quite welcoming of foreigners, but there is a hard gentlemen's agreement that if you're in Japan you do as the Japanese do. Those who can adapt are welcomed, those who can't/don't are excluded and ejected sooner or later.
The Hiroshima museum, while advocating for a nuclear free world, has an interesting take on why the US dropped the bomb on them.
According to them, the US dropped the bomb because they wanted to show their strengths against the Soviets. It makes little to no mention of the bloody battles in the Pacific.
> instead of a more self-reflective "nationalism is terrible" or something along those lines.
It used to bother me a lot, until I realized that
- the US purposefully left the Emperor in place with only a slap on the fingers ("you're not a god anymore...except for those who still believe you are")
- all surrounding countries have incentives to to keep distances from Japan (in particular as long as the US are there, Japan and China will never be allies, same for Russia), Taiwan being the exception.
I see no future where Japan nationalism is truly solved, short of these two things also getting solved. And boy is there no end in sight to this.
>the US purposefully left the Emperor in place with only a slap on the fingers
This was a deliberate political decision in an effort to not repeat the grave mistake of how post-WW1 Germany was handled which essentially led to WW2. Denying Japan of their identity and dignity would have risked an eventual WW3, and the US did not want to even entertain the possibility.
It also didn't help that practically all of Japan were not going to see their Emperor deposed or worse; Japan was willing to compromise on literally everything but the Emperor in making peace with the US and the west, and the extended Imperial family along with all the other nobles thereof lost their titles and powers in the post-war occupation and restructuring.
I think we're mostly in agreement. It was a strategic move and it might have helped a lot letting Japan get back on its feet. And it's also the move that left the deep deep nationalism in place and it's still here today.
Perhaps there was no way to have one without the other, but at least I want to look at it as a series of cause and consequences.
Crazy popular anime girl representations of WW2 battleships is the most funniest form of that reality IMHO.
> I'd argue the “nuclear taboo” is just the product of.. I don't just seeing one nuclear test video?
And yet some high ranking military planers were seriously pushing for employing nuclear weapons in Vietnam. Do you think they just haven't seen any nuclear test videos?
> It's a bit unclear to me why you need an organization that advocates against nuclear weapons.
Because humans keep building, and fielding nuclear weapons. Not sure where you live, but chances are good your taxes are used to build, and maintain nuclear weapons and the means to carry them.
How "stable" are these kinds of slimming tweaks though? In a rolling release setup, aren't you going to have extraneous packages semi-regularly drag in all of Python or Perl accidentally? The setup might break and you'd not even notice?
I find the premise of a carefully re-compilable/re-creatable system very appealing, but not having a stable LTS style release rather incongruous. It takes a huge effort to get all the pieces working together - and if it's rolling and the sand is shifting/breaking underneath you it feels you never reach a meaningful stable system. Sure you can recreate your well tested working configuration, but the configurations is effectively immediately out of date and unmaintained once any packages are updated
I think this is why they effectively only target x64. I'm not a "distro guy" so maybe I'm missing something. It seems it'd be sensible to just 1-to-1 copy Ubuntu LTS package versions (+ patches) and build a NixOS "stable" version that can be patched and updated as people find issues
> I think this is why they effectively only target x64
Nix and Nixpkgs is the best in class when it comes to cross platform & cross architecture support. It has good support for x86_64 / aarch64 /macOS / Linux. Getting Musl or static variants of existing packages just work for many packages. There's even some work on BSD / Windows support. Cross compiling is far easier to setup compared to other package managers. If anything, other projects should be copying what Nix is doing.
NetBSD's pkgsrc has always done extremely well for me for that.
I'm not sure how feasible it would be to compare nixpkgs and pkgsrc given how different they are, but I'd encourage people who need that to poke around at both and see which one feels like a better fit for their use case.
Almost all of the changes flip an official setting. Those stay around for a long time and get a proper deprecation notice when they go away, so you won't be surprised. Replacing systemd-minimal with the full version may potentially cause some edge case issues, but it's the same package with more features enabled, so I wouldn't really expect any.
Nothing will break when the package gets updated as long as you keep to your specific release - backported changes are backwards compatible.
So naive question.. but how can they ensure all the water upstream is clean?
I guess in Copenhagen its water is coming from the Baltic so maybe it's less of a concern (short of container ships having issues near the city). But the Seine river flows through many communities before it reaches Paris. Many opportunities for actors to illegally dump things in the river and for all sorts of nasty runoff agricultural and otherwise to make it in periodically along the whole stretch.
Continuous water testing at the city limits also sounds impractical
> Continuous water testing at the city limits also sounds impractical
Why? Surely a small team of a few people could have that as their job, and it would be completely worth it, to help keep all the people that want to swim safe.
And like, aside from the manual testing of the water that this team would do once or twice per day probably, they could have a few different sensors to catch some of the most likely kinds of pollution.
On top of that add hefty fines and maybe even a year or two of jail time for anyone caught dumping pollutants into the river, and you have a good disincentive against polluting the water.
And have a strong sense of pride of nature in the country so that people will naturally want to be mindful of the environment we live in. Promote this kind of thinking in schools and in public service announcements (billboards, ads, etc) from the government.
It's not technically impossible to continuously monitor a river, but as the neighboring comments shows, it's kinda of cutting edge stuff and basically nobody is doing it. It's also very much not cheap. Pinpointing where upstream someone dumped stuff in the middle of the night is virtually impossible
Advances in remote sensing are making continuous water quality monitoring much easier. At our company we use a combination of satellite imagery and in situ optical sensors to monitor rivers and reservoirs. As well as a general water quality index, we can estimate concentrations of harmful nutrients, chlorophyll-a, phycocyanin, suspended matter, dissolved organic carbon to name a few.
A further advantage of satellite remote sensing for water quality is that it can be done by a neutral third party, without permission or access to the land, which can help bring a bit of objectivity to the politicized narrative around water quality we are seeing at the moment.
multiple daily satellite images of the whole length of a river... I know you can purchase these kinds of satellite products, but as I understand it - it's incredibly expensive. Doing that all year round seems cost prohibitive
It seems to be normal practice. Two weeks ago Russia poisoned a river flowing across the border into Ukraine. The standard monitoring tools and infrastructure seemed sufficient to monitor the situation.
Yeah, it is helped by the geography. The channel in Copenhagen isn't a river, it is directly open to the North+Baltic seas, so we don't have this runoff type challenge of other European cities.
I think it's a general issue of developers with tricked out machines and fast internet connections developing software for everyone else. The reason the CLI is fast is not because it was carefully engineered that way, but because most of the software was developed when computers were slower than the chip you'd find in a washing-machine these days
example: flatpak. Last I tried - tab-outcompleting to install a package makes a network request for the application list. This ofcourse means you don't have to maintain a cache like `apt` and certainly makes things easier. I'm sure this makes sense if you're on your macbook pro in a cafe in Cupertino. But it was nearly unusable (whole CLI locks up and hangs) from my Core m3 computer tethered to a shitty network in a 2nd tier city in China.
> I think it's a general issue of developers with tricked out machines and fast internet connections developing software for everyone else. The reason the CLI is fast is not because it was carefully engineered that way, but because most of the software was developed when computers were slower than the chip you'd find in a washing-machine these days.
I think in the context of the ongoing 'CLI renaissance', what this misses is that many of the most recognizable tools which emerge from (or perhaps kicked off) the contemporary 'CLI renaissance' are very carefully engineered with performance in mind. Ripgrep is, to me, the most vital of all the 'next-gen' CLI programs. GNU grep is already incredibly fast, and ripgrep manages to be faster, to take common-sense shortcuts, to add in a few extra conveniences (like --replace, so you don't always need to pipe to sed or awk or whatever when you want to do a very simple transformation) without going nuts and losing focus. Its author, burntsushi, has written here on HN about their implementation as well as GNU grep's and other regex implementations, and it's clear that the predecessors have been studied with great care and respect.
I love many newer CLI tools, and this pattern holds for all of them. Consider, for instance, `jq`, which has become a 21st-century complement to vital staples like awk. This is even the case for many tools whose purposes are largely 'cosmetic', like `bat`, which more or less exists to be a more performant replacement for older colorizers like `ccat`. As cringey as the buzzword 'blazing fast' has become, Rust CLI tools are typically in tune with the general cultural emphasis of speed in the Rust community. And many Go CLI tools today are rewrites or clones of Python or Ruby tools, which were written expressly to achieve improved performance.
This also seems to hold for next-gen CLI environments: one of the main advancements most next-gen shells (e.g., Elvish, Nushell, Oil) offer over PowerShell (which introduced structured pipelines to the shell world) is performance!
This doesn't mean that every single new CLI tool is well thought-out, or (if it has direct antecedents) better than its predecessors. But I don't think the idea that new CLI tools are generally written without care for performance or consideration of the past is borne out when you look at what's out there.
This is really a massive release with many cool new features
My personal favorite is add-libs
You can now write single file demos or minimal examples for issues. Really lowers the friction to share small runnable snippets with people
You can also actually use it to demo Java libraries as well without all the Java boilerplate. Just poke around in the REPL and paste code into a comment on HN or wherever and anyone can replicate your "setup" and get it running exactly the same. No need to clone a repo or anything
- the first line downloads a library and adds it to the running session
- the second and third line add the library to the REPL's default namespace
- the rest of the code makes an axis and plots some random values
- the output is then serialized and send out the REPL output
You should get a little SVG plot on the output
PS: Make sure you have version `1.12` by running with `clj --version`. If not, then (re)run the instructions here to get the latest version: https://clojure.org/guides/install_clojure
Parent specified a RC version, does it automatically use the latest RC versions as well? AFAIK, it only uses the latest stable version, but I could be wrong, it happened before.
I recall that Atlassian had some kind of scripting console where you could run Groovy and interact with its API / objects. It was useful for exploring when writing plugins for bamboo or Jira ...
Haven't used neither Java's repl nor Common Lisp (just read about both of them) but at a glance Clojure's repl is much closer to CLs repl than Java's.
In fact, I think it's confusing to call the repls of language like Ruby, Java, JavaScript et al "REPL" at all, compared to what lisps offer, as the experience is so different. They're more like "Code evaluators" than anything else.
Typically when using repls outside of lisps, you'd type your code into the actual repl window, while in lisp-land you typically connect your editor to the repl and program like usual, selecting stuff to evaluate and so on.
> Typically when using repls outside of lisps, you'd type your code into the actual repl window, while in lisp-land you typically connect your editor to the repl and program like usual, selecting stuff to evaluate and so on.
I think that's neither typical in the history of Lisp nor in other languages. For example in Mathematica and Jupyter one interacts via a Notebook interface. Smalltalk interacts via an integrated IDE. Many editors connect via LSP to language servers.
In Lisp the idea of an editor connecting to a Lisp is a bit of a historic accident. After the AI winter the Lisp development environments were no longer used.
A typical way to start Lisp from an external editor was via the editor starting a subprocess (the "inferior Lisp") and talking to it. GNU Emacs did that with IDEs for Lisp, like ILISP.
The next generation used GNU Emacs as its external development environment (instead of developing a new one in Lisp) via a network interface. SLIME was the most important one, with SWANK being the component loaded into the external Lisp, which provided a server interface.
Unfortunately the SLIME REPL itself (its read eval print loop) is not great (in general SLIME is okay to use) and other languages sadly copied the SLIME model, failing to copy various other important REPL features of Lisp. For example Clojure lacked the error handling of Lisp REPLs, which typically provide features like break loops, where one can inspect and repair errors. SLIME goes directly into a backtrace window. Thus people copied it, without knowing that there is a tradition of completely different REPL interaction. GNU Emacs is bad at multitasking, thus one REPL buffer could block the editor for a while -> multiple REPL windows were not that useful. Another way of working got lost...
The built-in editor. With LispWorks I don't use GNU Emacs. I have GNU Emacs configured, so that I could use it, but I don't... I use SLIME with SBCL, but mostly because of SBCL, which is a great implementation.
I'm faster and more in the flow with the LispWorks IDE.
> In fact, I think it's confusing to call the repls of language like Ruby, Java, JavaScript et al "REPL" at all
Agreed. I always call them “consoles,” since I work largely in JS and that’s what the browser calls it. There’s no way in a console to jump into a module and modify a single function without resetting any state that the module was tracking.
repl as a name kind of describes the requirements for something to be a repl - it has a read-evaluate-print loop. It would be more confusing to say that something with a read-evaluate-print loop isn't a repl.
> Java's REPL is like a kick in the nuts compared to using one in Common Lisp.
An IDE connected to a running Java process via JDPA/JDI (Java debug interface) is probably a better comparison.
Sure, Common Lisp will allow you to load more substantial code changes into the running process, but using JDI you can "break on specific/ all exceptions" which will allow you to inspect code before the stack is unwound, you can drop frames and re-run stuff possibly after changing values.
What's funny is that I started noticing and using these possibilities at my Java job while learning Common Lisp. Before learning about Common Lisp I was almost exclusively an edit/compile/run guy, now I often take the shorter route of edit/CTRL-SHIFT-F9.
Many tools are like that, unfortunately Common Lisp didn't took off, and we are still catching up, see Python and Machine Learning, instead of using a powerful dynamic language with native compilers.
I don't think this is generally true and the generalization is actively hurtful. Promoting a skewed/miserable perspective on academia. It all depends on the institution, your funding situation, your field etc. The miserable academics are the ones that moan the loudest. There is often an online circlejerk of whining academics that wind themselves up (esp PhD students). Also the ones that are barely scrapping by are the ones that need to resort to bullshit. You may be able to game your stats but people can smell bullshit from a mile away. Everyone will know you're just good at playing the system
"Complainants and their critiques can be safely discarded because they need to git gud."
She states in the first three minutes of the video linked above that she was excelling academically. How bizarre to observe a lack of research in a thread complaining about how the academy has drifted from the conduct of pure research. Three minutes. One hundred twenty seconds. That's all it would have taken.
Do you use all 20 regularly? Because if you don’t, there’s a chance that next time you try to login to one of them on the web they’ll ask you to add a phone number and not let you continue until you do. But if you have them setup in an email client, it should still work.
So sure they can very reliably and safely deploy... It just doesn't feel like they've actually deployed anything interesting in 5+ years (except maybe some AI stuff). From the outside it looks like the company is perpetually refactoring
history's biggest yakshave...? not surprising for a programmer-run company
I'm sure it still matters to bring down the power and server bills. But one can't help feel like they could be doing much more
The "Tivo-isation" clause? You'd want AGPL but without that bit? That would be strange. I doubt Linus likes AGPL either because, unfortunately, his relationship with the FSF is always going to be sour. He's one of most stubborn people on earth (for better or worse).
As I say in the neighboring comment, I think the two compliment each other a lot more than v3. Linus would get even more code contributions .. I think he'd be happy
What rationale would that be? I doubt the FSF would write a version of the AGPL designed to let you use DRM to end-run around it if that's what you're getting at (you can always write such a license yourself, but, why?)
I mean ... Not to rehash all the v2 VS v3 arguments ... But essentially you only care about the source code being shared and you don't care about tivoization and forcing additional hardware requirements or requirements that "used code" is changeable by endusers.
The AGPL's extension just increases any modified code's availability. It's extending the principles behind v2 to networked devices. You gotta share your changes and you can't cleverly avoid it by doing a SaaS instead of selling software/hardware
It doesn't extend the v3 principles (which increase end user's rights). That would be to force companies to allow users to modify and run modified code on the networked device/server (which would be the networked equivalent of a anti-tivoization).
So the AGPL's idea pairs more naturally with v2 in my opinion
I find the Chinese model of bike/scooter lanes w/ barriers integrated into the main road a superior model. The other critical point is integrating bus stops into "islands" in the road so the bike lanes go behind the bus stops is critical. (a stopped bus with passengers going on/off essentially closes off the shoulder for an extended amount of time). Granted the main roads in Chinese cities are generally much wider so I'm not sure if it can be miniaturized the same way. The "turning area" is very useful concept for unblocking traffic and helping with visibility, though it does take up a lot of space. However the one in the example only accommodates one turning car at a time
reply