"developer" is a slightly weird way of putting it. osm.org is the contributor portal and demo site for OpenStreetMap, and yes it is not and never has been intended as an end user replacement for Google Maps and similar offerings.
The main purpose of the maps on the site is, besides showcasing some topical uses of OSM data, rapid feedback to contributors, which is something that required specific development so that can be provided with vector tiles too.
The 'late to the game' narrative seems to be a bit misplaced in any case given that OSM data has powered essentially all vector tile use outside of Google over more than a decade.
To answer the question: somebody needs to do the initial work and it's a further moving part that needs to be kept running (as the other responses point out such a distribution would likely use PMTiles as a container format). Given the current finances and staffing of the OSMF likely not top priority.
That's really convenient - I zoomed the map to an area in my town, clicked on a place, and even though popup is just raw data, it let me see which fields hold which values (which I could then feed back into pandas search expressions on the parquet files.) Just little things like "locality" is city/town in the US, and "fsq_category_labels is where I'll find Ice Cream Parlor".
> Foursquare and Overture places are like many geolocation-centric datasets: users aren’t supposed to ever see the raw data, either in a list or on the map. You have to filter by a confidence score. Otherwise, you’ll get tons of user-generated junk – pranks, mistakes, etc.. In the past, Foursquare would charge big bucks for the confidence scores as an upsell. If these scores aren’t part of the dataset, then no wonder the company feels comfortable releasing the data.
As Doctor_Fegg has pointed out further down, the OSMF provided raster tile service on openstreetmap.org is primarily intended to provide fast feedback to contributors and not for general purpose use, in particular not as a competitor to google.
The whole point of OSM is that you can take the data and build / design your own things. Yes it would be nice if there were multiple viable google alternatives based on OSM and other open data, but that is likely just a pipe dream, the economics don't really work.
Sure you could .... but to find something you would need to have the tile in question so you would need to calculate the tile to retrieve, and then find the object at the location (which is roughly equivalent to rendering the tile).
Doesn't seem to make sense when you can just run a nominatim or photon instance locally. Not to mention that currently you would typically have to add additional address data to the mix to get the quality of commercial geocoding services which makes the doing it via tiles even less attractive.
The whole point of vector tiles is that the rendering is local and controlled by a style configuration (except for the tile schema) that can be changed. So the brokenness you are seeing is either in the style or the library that is rendering the contents locally.
Well nobody claimed things are going to get simpler.
It is difficult to beat raster tiles in that respect. vector tiles split up responsibility for what you get visually over multiple moving pieces with different provenance and operators.
Partially because they're completely different stacks -- the client side is WebGL + Javascript, and the server side is whatever they've been doing for 15 years.
They're probably missing a raqm/freebidi or something in the stack on the client side.
Ah, so the input into the client-side isn't OSM-like data (i.e. OSM XML or some high-level transform of that), but rather something closer to a vector graphics format like SVG?
It's a mapbox mvt, which is protobuf. It contains the OSM data (obviously), but it's a specific format that's in wide use (mapbox-gl, maplibre, and many other open source versions). There are similar versions in pmtiles, which is basically the same thing in a http range friendly big single file which can be hosted on S3-like storage and used directly.
The difficulty is that the stack for rendering vector tiles in the browser is different than the legacy vector->png generation that's been done for ages.
Not really. You need to build geometries from raw OSM data (aka the stuff that you edit) then transform those geometries into MVT format adding appropriate attributes from the original data. In general you actually will want to normalize the data and throw out anything that is not included in the vector tile schema you are using. The net result is quite far from raw OSM data in any case.
PS: I maintain a project that stores actual OSM data in MBTiles format for offline editing, and yes proper editing apps have to do the above on the fly and it is the main reason they are not lightning fast.
Just to nip this in the bud, OpenStreetMap in general doesn't contain "translations" it contains the exonyms that are commonly in use for geographic objects. Most of the time things only have a name in the local language so there will be no value for other languages in the OSM data. Transliterations are a bit of a grey area in this context, but are definitely more useful than actual translations which tend to be garbage.
Further point: the data available in the vector tiles is defined by the vector tile schema and by far doesn't contain "everything".
The main purpose of the maps on the site is, besides showcasing some topical uses of OSM data, rapid feedback to contributors, which is something that required specific development so that can be provided with vector tiles too.
The 'late to the game' narrative seems to be a bit misplaced in any case given that OSM data has powered essentially all vector tile use outside of Google over more than a decade.