sp8962

Thanks for the blatantly marketing Overture on a Thread about downloading OSM data.

"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.

If you want to add more details (don't overdo it) https://wiki.openstreetmap.org/wiki/Simple_3D_Buildings

See https://community.openstreetmap.org/t/foursquare-releases-10...

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.

The article wasn't authored by anybody actually involved with the service or setting it up, just in case that wasn't clear.

Paul has written a blog post or two on the subject https://www.openstreetmap.org/user/pnorman/diary

No it doesn't.

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.

It contains the OSM data (obviously) ...

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.

Different use case.

Tippecanoe takes geojson and splits it up into tiles, we are talking about doing that with OSM data here. Typically you will want to apply some normalisation of the input data, then you need instantiate the geometry of the OSM objects, then split things up according to the vector tile schema in use and then write the tiles.

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.

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.

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".

... it doesn't?

One of the downsides of MVTs and the typical max zoom level of 14 is that that they do require more local resources than simply rendering a 256x256 bitmap.

For OSM the question is naturally would a complete migration (aka turning off raster tile support) exclude any noticeable number of people from contributing.

But right now that decision is still a long way off, the vector tile service hasn't even been integrated in osm.org yet.

Both apps mainly use downloaded/"offline" preprocessed map data in their own formats.

MVT format vector tiles are not remotely suitable for navigation or search (not ruling out that something could be hobbled together, but it would be a bit of a stretch).

No, because you've been able to self host (or have somebody host them for you) vector tiles for a long time with very little effort, and yes that will somewhat offload processing to clients, and, more importantly allow many styling decisions to be made by the client (but not all).

Static or infrequently updated vector tiles can be generated from OSM data by a number of tools, but those most popular right now are https://github.com/systemed/tilemaker and https://github.com/onthegomap/planetiler

The actual -new- thing is that the work Paul has done for the OSMF allows on the fly (aka in minutes) updates of the vector tiles. This is important for OSM contributors as a feedback mechanism and the main reason the OSMF operates the current raster tile service.

What is currently a bit out in the open is which usage restrictions will apply to to using the vector tile service as, just as with the raster tile service, the intent is not to compete with or replace third party services and a vector tile service could potentially do that.

You don't have to do this yourself, just understand that simple apps are a good way to bring new users in, ...

Except that the numbers show the opposite.

The easiest thing people can do these days is to take georeferenced photographs with their phones, best with a photo app that will record the direction the phone was pointing, for example OpenCamera on Android. Then take their time and then add the information either with iD (the javascript based editor on openstreetmap.org) on a desktop (or JOSM if they are savy enough), or on either of the mobile editors, but most importantly sitting down in peace and quiet.

While direct entry (on the phone) is what I would do and would recommend for anybody that already knows the ropes, it is going to be overwhelming for a beginner.

PS: I was commenting on the whole thread, and if you look through it you will see Steve mentioned as the OSM savant.

First OSM existed and was already quite good many years before we got access to Bing imagery (2010). Undoubtedly there was a big boost in some types of mapping due to a reasonable quality global imagery source being available, mainly buildings, but it isn't as if we couldn't have continued without it.

Since then a lot of things have changed and the global imagery layers (currently Bing, ESRI and mapbox, all three using Maxar for a significant part) are, in developed parts of the world, mainly just used as a lesser quality fallback. As an example where I'm making right now, I'm using state level, a federal and a global (non-Bing) imagery.

I need to quote myself on this thread https://twitter.com/sp8962/status/1534079141640904705

Steve hasn't been a relevant force in OSM for more than a decade and if you want to do OSM a favour, point people to the editor on openstreetmap.org, not any of the mobile or "simplified" editing apps.

That was an issue because of the validation pipeline Mapbox was using at the time, the vandalism had long been fixed in OpenStreetMap proper when the story hit the news.

So, yes, you are going to need to make a trade off between potentially more incidents, but faster repair, and less incidents, but being stuck with your current validated release for a while if something goes wrong.

PS: it is OpenStreetMap, no plural "s"

PPS: Meta produces a publicly available validated version of OSM data.

Impersonation is explicitly banned https://wiki.osmfoundation.org/wiki/Terms_of_Use If it applies to the situation at hand is naturally questionable.

Not really even that.

What is currently on the table is simply a way to cleanly differentiate between closed ways that are polygons and actual closed ways. Example roundabout enclosing a park. The problem is that right now this relies on determining this from the tagging. This could well be implemented as a flag on the existing way type and not as an actual new datatype.

There is at this stage no intention to revamp the way how we model areas that are more complex than the single polygons from above, that is with multi-polygon relations.

The more controversial topic is giving OSM way objects partially or fully their own geometry.

The former would have for all practical purposes no noticeable contributor effect outside of geometry changes always creating new versions of ways, contrary to the current behaviour which can be somewhat puzzling for newbies.

The later would be quite drastic, but would provide more benefits for at least some kinds of processing, for others not, as then topology would have to be inferred.

In any case the 90% of the discussion on this topic fretting about tagging is completely misplaced as literally nobody is even remotely considering changing that.

Likely because it is tedious (think watching paint dry) and expensive. And except if you take a shotgun approach to the service/goods classes you register in, you are still going to have exposure (in the US you need to provide proof of use down the road so its a non.starter there).

... or didn't respond in time to inquiries from Spain officials, it looks to me like the system (at least in Spain?) does not work.

As a rule you will not be contacted by the relevant trademark registering office. What happens is that the registration filing is published, and if you are opposed to it going through you will need to file opposition within a certain period after the publication.

That's why organisations with IP to protect typically directly or indirectly (that is via counsel) use trademark watching services. Essentially these scan the where ever the filings are published, and will send you alerts or whatever when something turns up on the radar.

Actually filing opposition is rather tedious and expensive, and particularly when different good/service classes are being used, sometimes difficult to actually be successful with.

No it isn't.

Contrary to doing the right thing in such a situation as Ben is doing with OpenMapChest, the operator of garmin.openstreetmap.nl went incommunicado years back, but refused to hand over it to anybody else or at least shut it down. Given that it is nearly always broken, not a good state of things.

You should be aware that it rather biased (doesn't show tools that are in competition to those that the author was involved in), and out of date.

To answer the question: no.

OpenStreetMap is constantly evolving in many dimensions. A fully fledged editor requires a significant investment to remain current (think at least one FTE).

It isn't a big business by many orders of magnitude.

The only businesses that over the years have been able to offer tile hosting as a sustainable business are very small mum and pop shops.

The large players are naturally not interested directly in the money aspect of providing the service, but in synergies with other, actually profitable, parts of their business.

And those in between are always in between pivots.