morganherlocker

This is likely the paper you are referring to:

https://www.nature.com/articles/srep01376

It states that 95% of people can be identified from just 4 location samples.

Along with dynamic rendering mentioned in other comments, vector data is sparse, so bandwidth is basically zero past a certain (surprisingly low) zoom. Raster tiles are a dense data structure, so you need to bake tiles to the maximum allowed zoom and clients need to download them. High zoom tiles also have higher entropy so you end up with a huge volume of images with low cache hit rates. It’s expensive for the provider and slow for bandwidth constrained mobile users.

Conflation is a huge accessibility concern and it’s not possible to mandate cross-government without some unified international government body. Even within the US, spatial data conflation is a major technical and political problem at the federal level, since the data is mostly collected at the state and municipal level, then rolled up into a Frankenstein dataset. The truly global nature of OSM is unique and the geographic diversity of coverage is unrivaled even among commercial sources, much less governmental.

As an EM, 20% of time spent on project management sounds about right. What you are overlooking is the time spent managing the people on a team. Hiring, recruiting, promotions, coordinating parental leave, working out visas with immigration attorneys, check ins, comp adjustments, etc all take immense time and energy to do properly. It’s a full time job and then some.

If you want stable, long lifespan software, this is exactly how you do it. You are also careful to only build on layers of abstraction that are also designed with this mindset. Yes, it limits what you can do and which features you can rely on, but it is an achievable goal for many critical lower level libraries.

I had a similar experience with the couchsurfing community 6 or 7 years ago. Beyond the basic hosting concept, there was also a large group of people who would meet up regularly in my city, which made it really easy to find activities for the guests you had in town. I really hope they find a way to keep going.

To be fair, contraction hierarchies are inflexible for exactly the reasons OP described. CRP (aka multi-level dijkstra) is more flexible, but there's always a trade off between query speed, pre-process/weight-update speed, and route quality. These services are very expensive to run at global scale if you need multi-modal or live congestion support.

> For example, do Uber and Lyft need machine learning?

Anyone doing large scale ETA prediction and routing these days is using ML models at various phases in the pipeline, from GPS noise filtering to road network data generation. You might get past the early stages of a rideshare or delivery service with more traditional naive models, but there are still significant efficiency gains to be made in even the most cutting edge systems today. For maps and navigation, this is especially true when you go global and need models that adapt to subtle cultural and behavioral changes across markets.

Sometimes I like to alternate between two features or bug fixes just to stay motivated with a bit of variety. It does break the kanban spirit a bit, but I avoid allowing anything to hang out too long in the “in progress” column to prevent procrastinating on a tough issue. Most of the time I only have one issue in progress at a time.

I use github issues with custom tags (bug, feature, docs, tests, etc). I am not too picky about what goes into the issue list, as long as it has a good title and description. I use a github project board to prioritize what to work on with a simple kanban setup. The backlog column is ranked with upcoming items up top and never more than 2 features “in progress” at once. This setup helps me focus on what I need to knock out without too much mental overhead, and is especially helpful when I come back to a project after a break. I also use the github milestone feature to track issues that roll up into releases. At the end of the milestone, I copy the list of completed issues more ore less verbatim into the changelog. I keep the setup as lightweight as possible, and avoid 3rd party integrations at all costs. The linking UX between the 3 features I use (issues, projects, and milestones) makes navigating the project convenient, without feeling like I am locking myself into github as a vendor. I avoid putting too much work into the kanban backlog beyond what’s in progress or next up for this reason, and releases are kept small so I could recreate them in a few minutes in a text file if I moved to another platform like sourcehut. In general, I avoid getting too far away from a basic todo list. Tools like Jira or Asana have loads of features that provide little value to a developer and a lot of lock-in.

I implemented something like this a couple years ago and the geometry files used for timezone lookup were surprisingly large (~200 MB at decent precision)! I ended up simplifying the geometries drastically to minimize data requirements and compute burden of the lookups, but if you need higher precision, server reverse geocoding may be your only option in constrained environments.

This would not provide very much privacy protection at all. Almost all trips will be unique with this level of granularity, so it will be easy to de-anonymize. I do privacy research with this type of data and have found numerous sources that used aggregation schemes with similar levels of granularity. In those public datasets, I was able to identify trips moving between a high school and a local planned parenthood, for example. 100m is far smaller than the size of school campus and most buildings.

To address privacy issues, data needs to be aggregated, with trip clusters with less than 5-10 trips dropped. Differential privacy strategies also exist, but dropping groups with low number of user contributions is the easiest solution to implement.

This is not quite incorrect. Some of the NYC taxi re-id demonstrations relied on reversing the hash for medallions, but most have not. In particular, the celebrity tracking did not require the medallion, since each record contains an origin and a destination. The identity of the driver across trips is irrelevant, since it is the passenger who is being tracked. The way this attack worked was to match an origin in the trip dataset to the timestamp on the celebrity photo. This revealed the destination of the trip.

In other cases, no photo is necessary (trips originating or ending at a residential address, linked to another sensitive location such as an abortion clinic).

There is a lot of research available on this topic. "Unique in the Crowd"[1], published in 2013, found that it takes only 4 GPS locations/timestamps to de-anonymize 95% of the population, with no other metadata. With 2 GPS pings, 50% of trips can be de-anonymized.

[1] https://www.nature.com/articles/srep01376

The collection in LA does include some car services, although not necessarily ride share yet. The collection protocol is designed for multimodal surveillance beyond scooters.

Municipalities need to comply with state law. In this case, CalECPA gives California residents a number of protections with respect to location data collection by government agencies. Generally speaking, collection is allowed when either a warrant is used or a user explicitly consents. Trip data reveals information about your relationships, life style, and medical status, so getting this right is an important issue for user privacy and safety.

To read more about this, the nonpartisan CA Office of Legislative Counsel has published an analysis of how the law applies, which found that this type of collection does in fact violate CalECPA in its current form [1]. The debate will likely come down to what steps need to be taken to make the collection scheme compliant.

[1] https://cdn.theatlantic.com/assets/media/files/calecpa_dockl...

Read up on differential privacy and k-anonymization. There are commonly implemented best practices for measuring and preserving anonymity in a dataset in non-reversible ways. It usually involves aggregating clusters of data and dropping clusters with too few unique contributions.

These techniques have a long track record in the private sector and with public entities such as the US Census, with a lot of formal research to back it up.

This does not work for most location datasets. It is easy to Re identify users in this type of dataset with a few lines of code. The identifying information is embedded in the locations and time stamps themselves. Research shows 4 randomly selected location points from a phone is all that is needed to uniquely identify 95% of the population.

Agree to disagree on this example I guess. "household" is referred to in the bill when defining re-identification, and this is an important improvement over the language in GDPR, especially when it comes to geolocation data, which is often sold at the household level (ie: Experian sells household level market segmentation profiles that tell you a lot about a person's behavior without directly linking to an individual).

The only other place households are referred to is in the section defining which companies the rules apply to, which is also pretty straightforward in a plain reading. If a company's number of consumers, households, or devices exceeds 50k, they qualify.

> (B) Alone or in combination, annually buys, receives for the business’ commercial purposes, sells, or shares for commercial purposes, alone or in combination, the personal information of 50,000 or more consumers, households, or devices.

No argument there; just pointing out that many of the common complaints around ambiguity are explicitly addressed in the text of the bill already.

Location data is explicitly called out as sensitive personal information in the text of the bill, so it's definitely not exempt as a category of data.

> (e) Many businesses collect personal information from California consumers. They may know where a consumer lives and how many children a consumer has, how fast a consumer drives, a consumer’s personality, sleep habits, biometric and health information, financial information, precise geolocation information, and social networks, to name a few categories.

As to how this will interact with free speech - in this case, speech of the company - is a bit of an open question. One of the assumptions of the bill though is that selling telemetry data about a consumer is not a form of protected speech, and that adding some restrictions to this practice is reasonable.

... and if you plan to handle this type of highly sensitive data, you should be prepared to provide some basic levels of compliance, including appropriate auditing of sensitive data along with informed consent from users.

Lot's of (mis)information floating around regarding CCPA. I recommend taking the time to read the actual text[1]. The text is not particularly long or dense. There has been a lot of speculation about complex compliance procedures, but the main thrust of the bill is to provide users with information about how their data is collected, who it is shared with, and the rights to prevent certain types of selling or sharing of said data. The leginfo site also includes non-partisan analysis (under the "Bill Analysis" tab) of the bill and amendments as it moves through the legislature, which is useful for getting an understanding of how specific issues are being considered and addressed. Something to consider is that bills change substantially through the amendment process, so often critiques you read are based off old versions of the text that have already been addressed.

[1] https://leginfo.legislature.ca.gov/faces/billTextClient.xhtm...

I went as a kid and recall locals often having snowmobiles as well.

Maps involve a wide range of these. Navigation involves a lot of computational geometry mixed with graph theory. Telematics deals with signal processing and machine learning. Cartography mixes GIS with rendering algorithms. The need for high performance and accuracy means there is a lot of motivation to continue pushing deeper into integration of the fields.

> I for one prefer the rise of the police state. Have you been to China lately? Amazingly safe.

So is the US. Meanwhile, China is already using their facial recognition technology to track ethnic and religious minorities and is currently "holding as many as a million of them in detention camps" [1]. We have already seen the US government move in a decidedly nationalistic direction over the past few years. Begging for a police state in the name of diminishing returns on security is playing with fire, and we do not need to look far back into the history of the US or Europe to see where that can lead.

[1] https://www.nytimes.com/2019/04/14/technology/china-surveill...

Other articles in this NYT series describe how location data is used for similar types of inference. Many of these systems are nearly impossible to opt out of, since they rely on deep rooted tech, like cell carrier chipsets, credit purchase history (tied to retail addresses), or even psychographic & demographic profiles tied to people in your neighborhood (essentially block level aggregates of commute & purchase data). Your strategy of spending time generating fake data online is not enough to really opt out of these systems, and many would argue that the burden of generating consistent dummy personas is already immense. To really opt out of your data being sold or used to target you, you would need to be ready to not travel with a cell phone, not use any electronic payments like credit/debit cards, or even conceal your place of residence from public sources through complex legal obfuscation. Obviously there are different levels of obscurity that can be had, but much of this technology uses dragnets with few practical ways to entirely hide.

Not at this time. It's an awesome project, but we started developing our traffic engines around the same time and needs quickly diverged. We do try to open source many of the low level pieces of our model as reusable libraries whenever possible, such as our graph normalization algorithms[1]. At the end of the day, much of the core is difficult to decouple from data engineering infrastructure which will be internal to each organization, due to the immense volumes of live data that must be handled to power a modern traffic engine.

Aspects of the model like noise reduction, modality classification, and speed distribution estimation also require lots of fine tuning that is specific to the telemetry being ingested & the usage patterns of the output. For example, our speed models learn and correct from observed errors in various situations over time, which is coupled to our internal metrics data.

[1] https://github.com/mapbox/graph-normalizer

Our traffic data is generated in house using anonymized location telemetry from our SDKs, much like most other traffic providers. The live speed predictions we generate for congestion and ETA models are competitive globally, providing the most accurate ETAs available in many parts of the world. Our accuracy today is particularly strong in the US, when compared to similar services.

Along with what others have noted, there is also risk associated with insulin therapy from hypoglycemia (low blood sugars). Low blood sugars can be deadly for type I diabetics, killing as many as 1 in 10[1]. This is at least one of the factors leading to insulin being a tool of last resort, and in fact, insulin is prescribed to type II diabetics with especially strong insulin resistance.

http://care.diabetesjournals.org/content/35/9/1814

Generic insulins are already available over the counter at any pharmacy in the US. The newer insulin variants are significantly easier to use safely, since they require less frequent injections (long lasting insulin) and have a faster response time (short lasting insulin used when ingesting carbohydrates or correcting high glucose). These newer variants require a prescription that is typically only issued by an endocrinologist who will require a visit at least every 3 months. I’ve had type 1 diabetes for 20 years now, and have only had my prescription changed a couple times over the entire period. 100% of my medication-related complications have occurred during times where I was unable to acquire a prescription for these higher quality insulin variants, either due to a change in doctor or insurance. Pre-ACA it was common for people to be locked out of insurance coverage of these drugs for up to a year without covering impossible markup on specialist care, and protections for pre-existing coverage are back on the chopping block as we speak. Even today, travel away from my doctor can result in stressful prescription renewal logistics despite having no change in dosing for over a decade. After seeing a doctor nearly 4 times per year for 20 years with almost every visit boiling down to “ok, here’s your renewal, see you in 3 months”, I’m not sure I understand the value for me personally. If someone wants to abuse insulin (I’m not sure why they would), they already can with a bottle of humulin, available at their local Walmart for about $20.

I’ve absolutely benefited from my endocrinologists over the years, but 80 appointments for 2-3 prescription changes (prompted by my request each time) seems like excessive rent seeking.