It is usually also much more finicky with regard to address syntax. Google Maps does a good job handling spelling mistakes or ambiguous addresses. OSM is not on par with GM, yet.

Yeah, I've heard that. GM is better at lower qualitys. But then search is google's main skill, and addresses can be all over the place...

Actually, "has all of the addresses" doesn't make much sense.

The way most geocoders work is by having street segments that are split at certain points and have from/to ranges of addresses. Here is a SO questions I asked many years ago that explains the logic:

http://stackoverflow.com/questions/10991330/how-does-the-goo...

In the US, a big chunk of OSM is based on a Tiger ingest. Tiger already had the segments split with the ranges (albeit some areas are not that accurate). In theory, you could still have a nice geocoder for US (the same is true for other countries like Germany).

The current crowdsourcing workflow of how people edit data in OSM makes it attractive for display (i.e. there is no need to split the street segments and add the address ranges for "pretty display"). But it also causes people to not edit the address ranges, snap the edges, etc, which just means that as a routing or geocoding dataset it is arguably actually worse.

You don't need _all_ the addresses to geocode. In theory, you could start with a particular country, clean it up for that problem. But right now, that is not the emphasis of OSM. The emphasis is a pretty base layer. For that OSM is awesome. For routing and geocoding, not so much.

OSM can be really good at routing. OSM cycle routing knocks the socks off Google, for example. But I'm with you on geocoding. (Personally I'm not entirely convinced that geocoding data wouldn't be better handled by a separate database.)

Routing is only as good as the data it is run off from. To do routing correctly for cars, you need direction of segments (one way, two way, only certain kinds of traffic like cars vs trucks, etc), some way to measure the cost it takes to transition the segment (like speed), in some cases number of lanes for "bear right or stay left type of directions" and even more difficult, z level connectivity (for example the Bay Bridge in SF has a set of segments that go above in one direction and another set of segments that go below - exactly in the same direction - right on top of each other).

Search for Navstreets Reference Manual for an example of Navteq's complicated schema for routing: https://www.google.com/search?q=navstreets+reference+manual

I really wish OSM was good enough for those two things... right now, it is not there yet.

Sure, yes. OSM has more of that data for cycling than anyone else; that's why I said OSM cycle routing is better than Google's. It's not there for cars yet (more OSMers survey by bike than by car), but all the things you mention are in the OSM data model, and all but number of lanes are commonly tagged in the best-mapped countries. It'll come in time.