In the logistics industry the commonly held wisdom is that there really isn't any accepted system for "how street addresses work". Different countries have completely different systems, and even within a country there are often many different conventions.
The thing that really matters in delivery is whether the address on the consignment has enough information for an operator to complete the next leg. By the time an item makes it to the region where the delivery address is situated, the local operators usually have enough understanding of the local system to get the item to its destination.
Even if the city in the article has a well defined system, it's probably not feasible for a global product like Google Maps to understand and encode every regional system. This is the problem that geocoding schemes (what3words, etc) are meant to solve, creating a single system that applies globally. But like many "rational" systems that attempt to replace entrenched practices, they struggle to gain traction.
That a building|property will have only one address.
Sometimes (eg: rural Australia) property addresses are updated from an older numbered lot based system (that goes astray when properties are subdivided and infill houses appear) to a system that numbers houses by driveway distance from last major intersection.
For five or ten years a house can be recieving mail or be on the records with both the old and the new address.
I think this idea that a building/property can have more than one address can happen in the United States too. The way I see it, it is because a ZIP code can be associated with a list of cities that are categorized as “recommended city name”, “other city names recognized for addresses in this zip code” and “city names to avoid”. [1]
So as an example, if you use the UPSP Cities by ZIP Code to research 77005 and you would see that they recommend using the city name of “Houston” for mail, but they would also recognize “West University Place”. There’s also a city called “Southside Place” which should be avoided when it comes to sending mail. But then that kind of makes me think that if a house is within the limits of one or these small cities, then it could in theory have the same street name but have two different city values in different databases.
Then on the other hand there’s a somewhat related problem where a small town or village (e.g. Somers, WI and Scotland, CT) can have multiple ZIP codes and that ends up causing a lot of headaches for the residents of the town since they all might live nearby but then each section of the town might end up associated with some other larger city it’s closest to.
I know of a house near Chicago that has two addresses with different street names. It's on the corner of an intersection and the "mailing address" is different than the "front door" address.
Not that there's a mailbox on the mailing address street. (There's only a small side profile of a house/yard on the mailing address street side). There doesn't seem to be a good reason for the mailing address.
> The way I see it, it is because a ZIP code can be associated with a list of cities that are categorized as “recommended city name”, “other city names recognized for addresses in this zip code” and “city names to avoid”. [1]
This one affects me personally and it bugs me programmers think that they know better than I do about my address when I try and enter the city name and zip code, then they "correct" the city name based on the zip code and make it read only.
a) what was the point of me entering the city if you were going to fill it in anyway ?
b) this has happened in the last two cities I've lived and is dirt common around a major metro area in the United States. Stop autocorrecting user entered data, let them be wrong!
You can pick from multiple city names on tons of addresses. But that's a lot less exciting than having multiple completely separate numbers or streets for the same building.
I suppose it is, but to me it came as a bit of a surprise that if I want to send mail to someone in a certain area, I can essentially toss a coin when trying to figure out which city name to use as long as I don’t use certain ones that are discouraged names. I believe my ZIP code has two city names I could use, but I would never use the non-main one because in my mind, that other city is miles away.
That struck me, although I already knew that a ZIP code could span multiple cities and sometimes even states. I just thought there would be no confusion about which city name to use.
This happens in metro areas quite frequently. I used to live in a suburb of Atlanta that had a valid address in "Atlanta, GA" and "Suburb, GA" - which was a common annoyance when using delivery apps or service area locating systems as which address was considered "valid" often changed depending on the provider of their mapping API.
There’s also the question of unit numbers and whatnot. In some addressing lookup systems in the US my address is 525 Some Road Unit G; but I have encountered systems that treat it as 525G Some Road.
The unit is usually formatted as either `{building number}-{unit number} {street name}` or `{building number} {street name}, Unit {unit number}`. But both resolve to the same thing.
What I like is that address box 2 (sometimes unlabelled, lives under the address box) exists specifically for unit numbers. So, I'll put in my street address in two lines:
Street Address :792 Charleston Avenue
Street Address 2:555
At which point, almost invariably, it'll say "Do you want to accept the Post Office's recommended address?"
Street Address :792 Charleston Avenue 555
Street Address 2:
Why provide the second address box if even in the one case where it's relevant and appropriate to use it, you're going to just stick the unit number in the first line anyway? It's so silly!
It also happens in places where a house/building spans two streets, and gets an address on both. Same reason some buildings get multiple numbers on the same street (happens a lot if they want to keep the option to later split entrances and give them numbers for instance)
I used to be a EMS call taker/dispatch (911) in Ontario, Canada. Addresses could be such a pain, especially in the the more rural areas. There were multiple townships around some bigger cities. They had different naming schemes and suffered from a similar problem that you mentioned. Many of the addresses also had old addresses. Our system would luckily often have both versions of the address stored, but not always. Additionally a lot of our roads have both numbers to address them by, such as "Regional Road 12", but then they'd also have an actual name. Almost every went by the actual name, however in the rural areas sometimes they had old real names, but it never was "official" so it isn't even listed.
Overall addresses are such a mess, and they are a mess even for governmental agencies like this one.
That's neat, thanks for sharing! We had the ability to accept a what3word location however it was a really convoluted process to actually attempt to use it. Unfortunately I never personally had anyone use it to give a location, even though it probably would have helped in many cases.
Had some calls where people would be hurt in a forest on a trail system and it was pretty common for people to not even know the name of the trail they are on nor which street they entered it from. Sometimes the GPS location the phone provided to EMS would help, but it also wasn't always 100% reliable, especially if they were in a forest. So being able to have them look at a map on their phone, pin where they are, and give a what3word location would have been immensely helpful.
The kind of system you linked to would also have been quite helpful for the other problems I mentioned.
I don’t know how they came to be, but in rural America I have seen houses which have signs very explicitly saying that two or more addresses are all this one house, so please deliver anything addressed to any of them.
The building in that example does have only one address. The old address is not valid any more. People just accept the erroneous use of the old address for the sake of expediency.
It has at least two official addresses each with a [time frame] of official validity.
When merging records the old address, no longer valid with the local land management agency, still appears on old notices and on current state and or federal records (as land naming agencies are layered in some locales with changes taking time to perculate).
The old address is "the correct address" in the context of birth records, old newspaper articles, last years tax records, etc.
You're technically pedantically correct .. but in a manner that's moot when faced with the realities of day to day day reconciliation of meaning of text on an envelope or document.
Besides that, in Buenos Aires, for instance, every access to the street has its own address. A building with 2 entrances (front door and garage) has 2 addresses, etc.
Where I currently live, my street has no name, my house has no number. If a package is delivered by mail, my phone number needs to be put on the package, and the local delivery operator calls me to either pick it up, or I send my location through telegram and they deliver it to my house.
It’s almost entirely impossible to order through Amazon et al using this type of system, it’s just not supported at all.
The same goes for my country or origin (in EU), they require my address in order to be able to send important mail. It’s just not possible because of the computer systems not accepting anything without a zipcode, address and house number.
What's preventing some local authority from just naming your street?
And what's preventing you and your neighbors from having a meeting, agreeing on a numbering convention, and putting street numbers on your house? I guess it would be a bit silly/meaningless if you don't have your street name.
Because most of my neighbors are expats and only renting and don’t actually own the property they live in.
Local authority doesn’t care, because it’s a very western problem. Locals rarely have problems with it, and use “go left the second street after the big tree near the market, and then it’s the third house on the right”.
Local people generally don’t use navigation apps like Google Maps, they don’t know how to use it.
A unique characteristic of Carmel-by-the-Sea is that there are no street addresses. Properties are identified, for example, as being on the "west side of San Antonio Street, 3 houses south of 12th Avenue". In addition to this, many owners give their homes a name. The name you choose does not have to be approved or registered with the City.
It’s just not accepted. So I’ll just fill in random numbers at zip code and street names and the delivery companies over here generally know how to deal with it.
I provide an address that looks technically correct, ensure it’s delivered with DHL, and then override DHL to pick up at one of their locations.
Also, there are special delivery companies like CamboQuick that take the whole process out of your hands and use (slow) ships freight to ship stuff from Amazon et al to Cambodia. You’ll have to wait 4-6 weeks, but they handle the custom clearance and everything and deliver it to your house for a $2 fee.
Why don’t you name your road and assign a house number? Either just make it up, or to make it more official contact your local government and propose a name and numbering scheme for it.
I remember a time before Ireland set up postcodes (zip codes) for the whole country. If postcode was mandatory field in an e-commerce address form, you couldn't mail stuff from the UK unless it was in Dublin. Dublin had postcodes.
I managed to find one site that would accept 'null' so the form would submit.
> From where the Chinese restaurant used to be, two blocks down, half a block toward the lake, next door to the house where the yellow car is parked, Managua, Nicaragua
> it's probably not feasible for a global product like Google Maps to understand and encode every regional system
That's not the original ethos of Google: organize the world's information and make it universally accessible and useful. I don't know about now but twenty years ago Google almost certainly thought it worthwhile to encode the rules of every regional system. Add that to Larry and Sergey's "healthy disregard for the impossible" I'm willing to bet that twenty years ago Google had almost certainly made it feasible to do just that: encode the rules of every regional system.
20 years ago I think the coverage area of Google Maps was still strictly limited to the US + UK. Like, the rest of the world map was empty.
But I worked on Google's geocoding (mapping names to locations) and reverse geocoding (mapping locations to names) systems 15 years ago, and encoding every local ruleset was absolutely not how it worked. Or even encoding any of them.
And what's described in the post are exactly the kinds of problems you'd have back then as well.
Some of these were upstream data quality issues, some were due to deep infrastructure problems that could not have been addressed without a complete rewrite, and others just basic recall/precision tradeoffs around the value of returning a result that doesn't match the query exactly.
I believe that there is no accepted global system for "how street addresses work", but there has to be a better solution then a business owner reaching out to a friend's cousin to try to get a serious problem fixed.
If my fixes had been published in the promised 24 hours then this blog post would not have been written but after two weeks this is the best idea I could come up with.
I think it is practical for Google Maps to understand the systems used in most major cities and then use this knowledge to reduce the number of errors.
I also think it is possible for the feedback system to work better. It does work sometimes, but it is slow and opaque and unreliable. It's even worse for bike directions.
> I believe that there is no accepted global system for "how street addresses work", but there has to be a better solution then a business owner reaching out to a friend's cousin to try to get a serious problem fixed.
The friend's cousin did what they could have done themselves, use the feedback tool.
Right. I (the friend's cousin) did that. And two weeks after the changes were supposed to take effect the directions are still broken and the customers of this business are still inconvenienced.
So I wrote a blog post. It is yet to be determined if that will help or not.
Given that Google Maps understands the rules for street addresses in Vancouver it seems like the problem shouldn't have happened in the first place and should have been auto-corrected and the fix should have been quickly accepted. But none of that happened.
Most non-nerds don't know how to use the feedback tool. That is the reality.
> Most non-nerds don't know how to use the feedback tool. That is the reality.
100%, you've done all you can! I enjoyed the article, but was just remarking that you weren't technically needed to fix the issue. Either the feedback tool works, or it doesn't.
Your bio says that you are a programmer at google. That says a lot to how impossible the situation is to most people. Google maps has been telling me bs for years. When I lived in Cyprus, asking directions to a business would often lead to empty lots. I assumed it was caused by competitors sabotaging the database with bogus updates..
You're making the perfect be the enemy of the good.
Making sure buildings are near the street listed, in the right range of numbers, is a system that works in most regions and should be encoded and used for checking data.
I wouldn't automatically assume that they don't have such checks. Checking an entry for reasonableness is a good idea, but it needs to be overrideable. Sometimes you'll need an entry that isn't actually reasonable by whatever definitions you use. And then you'll tend to have your workers get used to the override and not actually think about whether it might have a point.
So who's responsible for then figuring out what nested regions, and nested regions of nested regions, and nested regions of nested regions of nested regions, that then does and doesn't apply to?
For a practical example here, check out Mumbai, India in Google Maps and look at addresses of various businesses there, most of which amount to "Building Soandso on Road X near Landmark Suchandsuch in neighborhood Y" (ans often written in a non-standardized way, on top of that). To compensate, delivery apps there have you visually put a pin on a map as a standard part of checkout flows.
> it’s probably not feasible for a global product like Google Maps to understand and encode every regional system
Does it have to encode them all? Why not start out with one then at least Google Maps is a little better for some.
Besides that, how many systems could there be? There are only something like 10,000 cities on the planet. That sounds like the kind of task Google is built to handle.
I live in a small country of ~2mio pop, and we have approximately 6000 settlements with streets and street addresses and many different standards of numberings, depending on many reason, mostly historic.
Technically yes, a few thousand systems could be programmed into some google processing engine, but you'd have to manually classify every road to set the correct system, and even there, you'd never know what is a legit numbering scheme or what is an error.
For example, Cucumber street 1, 3, 5, 7, 9 on one side of the street and Cucumber street 2, 4, 6, 8, 10 on the other is a valid numbering scheme. If #3 splits his front yard and builds another house, you'd get "3a" on that side. If #6 buys #8, demolishes one or both buildings and builds a bigger one, that could become either a "6" or an "8", and the other would be missing. Then #7 is demolished and an apartment building is built there with 4 entrances to 4 separate building sections, so those would be numbered 7a, 7b, 7c and 7d, even though they're in the same building. #5, #7 and #9 are also a part of the same building (three entrances), but the building is older, the street was renamed and renumbered some time after, and each of the entrances got its own number. Then you come to #10, which is also a building with 4 entrances, but #10 goes towards Cucumber street, and the other three are facing the Lettuce street and are thus Lettuce street 6, 6a and 6b. Notice starting with the "6" here and "7a" above, well, that's because #6 lettuce street existed before the building was expanded, it kept the #6 number, but since there used to be a shed on Cucumber street #7, the new building starts with 7a.
Your "Cucumber street" is exactly like Germany works, as far as I can tell, including the even/odd split, and the a/b/c/d... when inserting new houses, or separate building sections. (I've seen as far as "h" in one extreme case, but I think after "d" becomes pretty uncommon.)
Anyway, if your little country is difficult for Google, they should probably skip it for now. Do New York first. Then L.A. Then Toronto. It doesn’t have to cover everything, just make things better for a meaningful number of people.
Are house humbers 6 and 7 next to each other? 6 and 8? What number would come next if the building numbers go 2, 4, 6, 8, ? If there's is a "7b", is there a 7 too? 7a?
> it's probably not feasible for a global product like Google Maps to understand and encode every regional system.
This is literally true when talking about the entire planet, but this is Vancouver.
There are many geocoding systems that do just fine with the considerable range of addressing schemes in the developed world.
Something very weird is going on here, like Google finding a cheaper method for geocoding that is probabilistic and yields a level of errors they are ok with.
> and even within a country there are often many different conventions.
You know who knows this? The tax authority.
> the local operators usually have enough understanding of the local system to get the item to its destination.
Large freight does not work this way. I worked on top of a ski resort for a while. We had a mapped address right where the ski left let out instead of the base of the hill. In the summer you could drive up to it on an ATV easily and a pickup truck if it hadn't recently rained. Somehow a semi truck driver for a freight company got this address and mapped a route to it. We were quite surprised to see the 53' box truck driving up the side of the ski hill.
> it's probably not feasible for a global product like Google Maps to understand and encode every regional system.
The information is encoded elsewhere and it's a bummer there is no incentive to make it as open and widely available as is possible. Although if delivery can rely only on partial information to "complete the next leg" then why can't address lookup do precisely the same thing?
> it's probably not feasible for a global product like Google Maps to understand and encode every regional system
I disagree, it's a requirement of being global. If you can't be global, don't. Meanwhile they have hundreds of thousands of engineers in their employ around the world, they have the scale to be correct.
I know this isn't what you said, but the idea that a small scrappy team of developers in one corner of the world can develop a system that works at all for the entire planet while dealing with the real world should be possible is just nonsensical. There's no reason Google can't be correct other than the fact it's unsexy to management that solving the problem involves hiring people who speak nearly every language on the planet and can connect and comply with enough governments around the world to get things right. Somehow that's not less surprising than sending cars everywhere to take photos of everyone's front doors without their consent.
> even within a country there are often many different conventions
Indeed... sometimes USPS even makes up their own "vanity city" names that don't exist. Or mailing addresses might use a different city name than where the house is physically located because of where the post office is physically located.
Google Maps may not be able to understand every regional system but it _does_ understand the system in Vancouver. It then, apparently, makes it too easy for exceptions to this system to get encoded in their database and makes it too hard to fix those errors when they are noticed.
I worked on a global consumer mapping app once. Among that team, the idea that address schemes were too inconsistent to be useful was also conventional wisdom.
And yet, as I mention in the blog post, Google Maps actually does understand how Vancouver's addresses work. It can find the location where a non-existent address would be if it existed. But for addresses like 138 W 6th Ave it chooses not to, instead trusting... well, I don't know what it's trusting. But whatever it is trusting is wrong, and is resistant to being corrected through the feedback tool.
Using `as` in TypeScript is a dangerous practice, since it sidesteps the entire type safety system. If it has to be used, it should be used minimally, in controlled circumstances. Using a system like this allows your types to be specified in a very small surface for re-use. If they have to be changed, they can be changed in one place (the schema) which will cause type warnings to flow out if there are any problems.
Futhermore, a lot of the value of these systems is to provide type safety within the query. You choose a typed column in your select clause, and then in your join or where clause the column type is inferred, and warns you if you attempt a comparison that doesn't work with that type.
If the purpose of TypeScript is to add type safety to your logic, why wouldn't you want type safety in the logic that happens to be database queries? I haven't used this library but have used kysely which seems very similar, and all the benefits I enjoy from TypeScript, I now enjoy in my SQL.
> It seems like a step back to have to write SQL in Javascript syntax with a non-standard API.
Like TypeScript, this is an attempt to add type safety and hinting to an untyped language: SQL. With that in mind, some compromises seem inevitable.
> …why wouldn't you want type safety in the logic that happens to be database queries?
The problem is you’re writing queries in Litdb’s Javascript/typescript-based query language instead of SQL, but the types it provides still aren’t real — you need to ensure they match the data some other way, just like with “as”.
What the types here really accomplish is code-completion. That’s nice but there are ways to do that without giving up real SQL. Not to mention databases have their own type systems, which differ from each other and typescript. Maybe they nail all the mapping, but I suspect their are misses (probably by not allowing valid things, since typescript is generally more strict that dbms’s).
Systems like litdb typically include (or work alongside) a schema migration tool, which either reads the current structure of the database and writes that back to a TypeScript file, or reads a TypeScript/schema file and generates a migration to update the database to match the schema. I haven't seen one that works perfectly, and it's up to you to keep it up to date, but as I said it shrinks the surface of where "mistypes" can occur.
It's quite similar to working with a web API. You can invent all the types you want, maybe generated from an OpenAPI schema, but if the server sends something different, TypeScript can't help you. That's not what TypeScript is for.
At the end of the day, most non-scalar TypeScript types "aren't real". Objects can be mutated at runtime, libraries can ship incorrect types, TS can be mixed with JS, etc. We try to introduce types as early as possible to catch a wide swath of possible errors, but where it's really important you still need to verify at runtime.
Having recently been down this journey with kysely, these type-safe query builders still seem to have a large gap when it comes to the return types of SQL functions and opaque types.
My current project uses PostGIS which uses opaque types for storing geometry. Geometry columns are added to tables via a function instead of traditional alter table syntax, and select/where clauses on geometry columns need to use PostGIS functions to render the column into useable data.
Unless a system like Litdb includes an easy way to provide type definitions for function return types, it won't be usable with an extension like PostGIS without heavy use of escape hatches, at which point most of the value is lost.
litdb does include support for registering TypeConverters for mapping custom RDBMS types [1]. The drivers doesn't include any converters for custom RDBMS-specific types yet, but you should be able to register your own in your App or even better submit a PR to the postgres driver [2] so it'll work OOB (tho it'll be dependent on whatever postgres.js can be configured to support).
Correct me if I'm misunderstanding, but this would allow me to register the desired conversion type for a basic postgres type, to and from JavaScript but not for the return value of a specific function or even a specific invocation of a function.
PostGIS uses a lot of functions like ST_AsEWKT, ST_AsMVT or ST_AsGeoJSON [1] to marshal data. While ST_AsGeoJSON will always return "text", ideally you'd want an invocation of ST_AsGeoJSON to return JSON to your JavaScript, but this wouldn't be true of all "text".
Even better, you would want to declare the structure of the returned JSON via a TypeScript type. GeoJSON is a structured format, so this would likely be a generic GeoJSON type wrapped around a custom type for the specific structure you expect for each geometry type / query.
Anyway, it's a tough problem to solve without introducing TS versions of each specialty function, which would be a large effort for an extension the size of PostGIS. For now I use typed raw queries via the sql<T>`` escape hatch provided by kysely, but if your library made this more ergonomic/safe I'd consider switching!
Type Converters lets you change the parameter value that's executed with the underlying provider (postgres driver uses postgres.js [1]) and what value is converted from the provider's resultset to your class property. So it would be up to whether the underlying provider can be configured to support the custom RDBMS type. If you leave a feature request [2] I can let you know when it's implemented or it's not possible with postgres.js when I get around to it.
Hey, I'm developing a different approach that may appeal to a Kysely user such as yourself. I'd be glad to get your thoughts on it :)
Raw SQL (or PL/pgSQL which can be quite powerful) with generated, type-safe client "bindings" (TypeScript functions). It also includes "declarative SQL schema" (instantly update the schema of your dev DB on file save). Generated migrations and "seed scripts" are also on the roadmap.
If any of that interests you, check it out (https://github.com/pg-nano/pg-nano). I would also be happy to discuss it with you on Discord (@aleclarson).
Solar and wind definitely make the most sense wherever feasible, but it's important to keep in mind you can't just build solar and wind farms anywhere. China has moderately good solar capacity in the north, but generation there will be seasonal due to how far north it is. The north of China is also not close to the majority of the population, so transmission will be an issue.
China's high to moderate quality solar capacity will be built out very quickly, and it won't provide enough to close the gap from fossil-based generation. From there, the cost of solar generation will rise as low quality capacity is developed.
China will need a way to import some of their energy generation, possibly through by importing goods like iron and steel that have a high energy production cost, from countries like Australia that can produce them using renewable energy (green iron / green steel) using Australia's almost limitless solar resources.
Since much of Australia's coal is also used in places like China to smelt their local and imported iron and steel, this could further drive down production of coal.
China is building a nation spanning UHV ("ultra high voltage") power transmission system.
> According to China Energy News, the combined length of the UHV transmission lines operating in China had reached 48,000km (30,000 miles) by the end of 2020, more than enough to wrap around the Earth by the equator.
That's because the big energy sources are in northwest China, and the big loads are in southeast China near the coast.
The US should have similar lines running east and west from the wind belt, which runs roughly from the Texas panhandle to the Canadian border. There's not enough transmission capacity out of that region. Some of this is due to opposition from the oil industry.
There are plenty of use cases where an established CSS framework is a good choice. For PoCs, internal tools or dashboards, or just short lived projects, you can get very far by utilising a framework.
But if you're building a product, or UX / design is important to your project's success, then I completely agree with the author. You will quickly run up against the boundaries of what the framework provides and start fighting it. The methods the framework uses for extensibility won't be adequate and will hinder your attempts to customise it in the way you want to. Starting with custom CSS means you build things the way that makes sense to you and your team, and avoids a costly refactor later when you decide to ditch the framework.
That does mean that your team will end up designing their own framework! Developers with enough skill and experience to do that well are not always easy to find.
I disagree with the criticism of SASS, but with all the new features landing in modern CSS, it's not nearly as useful as it was even 2 years ago.
One thing that's keeping my hand on the mouse and stopping me from going full keyboard, is the free scrolling mousewheel on logitech mice. I find it such an ergonomic and natural way to get to the right place in long documents (and code).
What I would really love is a keyboard with this sort of scroll wheel embedded just on the edge of the keys. All the keyboards I see with knobs / rotary encoders look cool but I can't see myself using a vertical knob for scrolling a document. Do any custom keyboard builds feature a mousewheel?
There are horizontal rotary encoders with click functionality (The component is called EVQWGD001). Unfortunately the pin layout differs from the vertical rotary encoders so you need a custom PCB or hack some custom wiring together. They're more common on split keyboards from what I've found.
You can buy a preassembled split keyboard with this from https://ergomech.store (I've been looking at purchasing one from them). There's also a seller on etsy who offers split keyboards with the horizontal encoder.
Around the turn of the millennium, I had a Logitech keyboard which featured a scroll wheel (and dedicated keys for media control, search and other stuff). I don't recall the model, but you might get lucky on eBay with a bit of searching.
[EDIT: After a bit of research, I found the model: Logitech Internet Navigator Keyboard]
Different levels of code quality are important for different teams / projects. Teams that are still discovering the domain and defining patterns should aim for a lower quality so they can iterate more easily. In this mode, knowing that code was written quickly and is fine to throw away / reshape is critical. Aiming for Very Good is likely to be a waste of time here.
In other projects, the domain is clearer, or the system already has well defined patterns that should be followed. In this mode fast iteration is also possible, but it's because the code is clean and follows strong patterns making it easy to understand. Good Enough code here is quite likely to slow the team down as they grapple with needless bugs and code that's hard to decompose / refactor.
The most important aspect of quality is that the team defines the level of quality that's needed for the project or the work being undertaken, and they deliver to that. Have the conversation up front about what level of quality to aim for and why. Then the team is on the same page, and everyone can move forward with the same expectations.
The problem for the last 4 decades has been getting people to admit that we were 'building one to throw away'. In the last 2 we've tried a couple of different tricks to get things done anyway, with varying degrees of success. But that's all external-facing problems
The internal facing problem is getting a team to agree to differing quality gates for different parts of the system - the absolutely knowable and the arguably unknowable parts should not be written with the same mindset if you want to maintain velocity. If you get lucky with the org chart you can fake some of that quality diversity via code ownership, but that's a rough approximation at best. People seem to prefer picking something static and not thinking about it too much, rather than having to reason about every feature. I'm curious to see what we try next to deal with this.
Mentioned in another comment, but if you like Baraka, seek out the film Man With a Motion Picture Camera (or Man With a Movie Camera), it's the progenitor of both Baraka and the qatsi trilogy. There's a version with a score performed by Cinematic Orchestra that is just amazing!
Some amazing music that never seemed to go mainstream:
The Cinematic Orchestra, great modern jazz with a beat. Try the album Everyday. If you're into film there's a version of the 1929 Dziga Vertov film "Man With a Motion Picture Camera" that has a score performed by them, also excellent.
Patrick Watson - Close to Paradise. An ecclectic concept album, one of my all time favorites.
Jaga Jazzist - Starfire. Their early albums are great also. Hectic, energetic ensemble jazz with lots of overlapping time scales and patterns. Sounds a bit chaotic at first but once you recognise the patterns it just clicks and is super fun!
The thing that really matters in delivery is whether the address on the consignment has enough information for an operator to complete the next leg. By the time an item makes it to the region where the delivery address is situated, the local operators usually have enough understanding of the local system to get the item to its destination.
Even if the city in the article has a well defined system, it's probably not feasible for a global product like Google Maps to understand and encode every regional system. This is the problem that geocoding schemes (what3words, etc) are meant to solve, creating a single system that applies globally. But like many "rational" systems that attempt to replace entrenched practices, they struggle to gain traction.