390 karma · joined January 23, 2017
This is a terrible idea. The behaviour of engines that do this is unpredictable and suddenly you lose data because the engine deleted a column.
IMO, brouter generates the best routes for bicycling with lots of options to customize for what kind of riding you want to do (road, trekking, gravel, recreational, commuting, safe and quiet vs. quick, etc.).
Right now I use brouter-web on my iPhone but it's really hard to use since the UI is really small and it's very simple to accidentally place a waypoint. After that, I send the GPX file to my bike computer.
A video mixer acts as the source and sink for the output and the inputs respectively, where a HDMI switch will just physically disconnect and connect the output port to a different input port, meaning the HDID negotiation has to be re-done every time.
As I've said, the solutions are there, and there is an actual demand for cheap vector tile hosting without all of the other cruft that is bundled in the commercial solutions but isn't actually needed.
The current offerings of google, mapbox, bing, etc are prohibitively expensive when you just need a small subset of their features.
The company I work for is a happy customer of maptiler.com which even offers routing and reverse geocoding. It might not be as great and up to date as google's, but it's more than enough for our apps.
Alternatives such as public transport, walking and cycling have always been gimped in favour of car traffic, lest the car driving populace complain.
To be fair, I haven't read the actual draft, just read some reporting about the implications for open source software.
As if you had the right to be angry at somebody just because they had the audacity to open source code and struggling with maintaining it.
Of course it is simple to say "communicate this clearly" in hindsight. And I kind of did that. Still there are users who expect more from me than I can give.
The article also discusses that. Of course there are better ways to do this than just closing it wihtout comment, even though the end result is still saying "no" to it.
I have open-sourced a library that I wrote for an in-production app at work, and it got a little too popular for me to handle like most open source "consumers" (even though they don't pay me) expect.
Every time there's a feature/pull request, I not only have to think about if the code is correct, but also if it would introduce breaking changes in the way it is used in that production app.
It's very mentally draining to visit the issues page of that repository, because it's full of people needing help or wanting to contribute work. But I can't handle them all within an acceptable timespan.
Every few months I take half an hour to clean up there, and then the issues list is already filled with disgruntled users.
> The response to an issue of "contributions are welcome" or "you can fork it" are inappropriate because the filing of an issue is not a request to fix. It is an issue reporting mechanism. But too often, maintainers become chippy about reported issues.
I agree in hindsight that it probably would've been better to just turn off the pull requests feature when creating a repository if you can't commit yourself to the potential workload it creates.
> Saying no is fine but please be honest and upfront on a repository's README. If someone says "this is open source but it's mainly a personal project and/or library and I will aggressively close issues", then that does wonders to set expectations. And I think that's the key idea. Setting expectations, upfront, is the key to effective communication.
Most of the time you don't realize that you really can't handle all that workload when you're still in the "honeymoon" phase of the thing you're open-sourcing. What are you supposed to do when it gets to the point where it's just overwhelming you to even look at the issues list?
Is there something that approximates this "effortless" experience using some cloud service and the freedom to use whatever software to manage and convert the photos?
I use the tunnel 3-4 times per week!