[HN Gopher] OpenStreetMap's New Vector Tiles
___________________________________________________________________
OpenStreetMap's New Vector Tiles
Author : marklit
Score : 336 points
Date : 2024-11-19 12:03 UTC (10 hours ago)
(HTM) web link (tech.marksblogg.com)
(TXT) w3m dump (tech.marksblogg.com)
| DemocracyFTW2 wrote:
| One clear advantage of the new SVG format is, apparently, that
| Arabic script is now, finally!, rendered the way it was always
| intended--left-to-right with unconnected letters /s
| rafram wrote:
| Yeah, I'm curious if that problem is baked into the SVG, or if
| the renderer has a "don't screw up Arabic" option that's
| disabled by default. You'd think nobody would design software
| that way, but Photoshop has that option, and it really is
| turned off by default!
| Symbiote wrote:
| They are just Unicode strings in the vector tiles (which are
| their own format, nothing to do with SVG). It's this
| particular demo that is missing basic Arabic support.
| string_value: "shr` lmdyn@ lqdym@"
|
| I can't read Arabic, but I know if I see "l " then it's
| broken -- "l" is correct: https://isthisarabic.com/
|
| Someone's already made an issue:
| https://github.com/pnorman/osmf-shortbread-todo/issues/9
|
| Found via what seems to be the announcement of this
| demo/preview service:
| https://community.openstreetmap.org/t/vector-tiles-on-
| osmf-h...
| SigmundA wrote:
| Mapbox Vector Tiles are not SVG, its is similar to geoJSON but
| encoded in protobuf. The renderer is going to typically be
| WebGL based in the browser written in javascript.
|
| https://wiki.openstreetmap.org/wiki/Vector_tiles
|
| https://maplibre.org/maplibre-gl-js/docs/
| memsom wrote:
| I wish they were SVG, that would make rendering them less of a
| headache.
|
| There is still no good library which takes in a MVT tile and
| spits out the appropriate PNG or JPEG for rendering in via a
| tile base mapping engine. There is still no good cross platform
| mapping engine that can render vector tiles in a way that is
| easy to consume. There are certainly engines on specific
| platforms, but unless we use something like Leaflet or
| OpenLayers it is hard to make it work with native APIs on, say
| Windows, MacOs, Linux, iOS or Android without needing to adding
| a whole browser engine on top of your app.
| dvdkon wrote:
| There are plenty non-web vector map renderers, but they
| generally provide a full GUI widget, not a simple "extent ->
| png" function. I don't think creating that would be too much
| work, though: Just set one of those libraries to render to a
| texture.
|
| Maplibre Native even seems to have a headless "render to PNG"
| backend: https://github.com/maplibre/maplibre-
| native/tree/main/platfo...
| mxfh wrote:
| If I would like to print vector-tile based maps to pdfs for
| handout's or something, is there any CPU renderer, server- or
| client-side that could output SVGs instead of rasterizing on
| GPU to bitmap at some point?
|
| I havent yet come across any renderer that would do this even
| partially, even before opening the whole can of worms that is
| text rendering.
|
| Closest thing I'm aware of might be _ArcGIS Maps for Adobe
| Creative Cloud_ but would need something that 's more like a
| library and preferably FOSS.
| InsertUser wrote:
| Recent versions of QGIS support vector tiles in the MVT
| format (like these ones). So with a suitable style you
| should be able to create a layout using vector tiles and
| print.
|
| Assuming you meet the relevant attribution/license
| requirements for the various bits you choose of course. I
| don't think any usage policy has been published for these
| tiles yet.
|
| Unfortunately there are some translation issues with styles
| for MVT sources so you might need to do a bit of fixing if
| you don't want to go the route of a paid plan with MapTiler
| (third party provider) who have a plugin.
|
| There's also a list of "print map" generators of varying
| types here:
| https://wiki.openstreetmap.org/wiki/OSM_on_Paper
| dvdkon wrote:
| QGIS can do this. It's a large dependency and loads
| Mapbox/Maplibre styles by converting them to internal ones,
| so it might look a little different than the standard
| Maplibre renderer, but you get the benefit of easily
| editing those styles.
| rob74 wrote:
| So while showcasing the brand-new vector tiles, they
| accidentally also showcased a pretty significant bug? Should
| have picked some city with non-latin script that's written
| left-to-right... er, maybe Athens?
| InsertUser wrote:
| They released them for testing purposes, originally on a test
| server and now a soft launch on OSMF hardware.
| https://community.openstreetmap.org/t/vector-tiles-on-
| osmf-h...
|
| The author of the blog post chose an area that doesn't render
| well. The various issues are being flagged in the relevant
| repositories as they are found.
| ajsnigrutin wrote:
| > Imagery should appear much sharper and switching the language
| of the labels should become possible.
|
| So, every eg. city-shape-vector (well.. polygon) will cary the
| metadata/text of the name of that city in every defined language?
| tantalor wrote:
| No but you could fetch tiles with only the text you need to
| patch the tiles you already have.
| roelschroeven wrote:
| Large cities already contain the name in many languages. See
| Paris for example: https://www.openstreetmap.org/relation/71525
|
| The usefulness of being able to switch the language depends on
| the availability of translations of course. It might give
| editors an incentive to add more translations for place names.
| maxerickson wrote:
| The tiles aren't necessarily a 1:1 translation of the data.
|
| The official tiles will probably be close though.
| M2Ys4U wrote:
| If there's a Wikidata QID associated with it then one can
| also use that to look up names in other languages
| sp8962 wrote:
| 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".
| ajsnigrutin wrote:
| Sure, but that's contained in the database, and then the
| tiles are generated that only contain one text (usually) in a
| png form).
|
| Now all the metadata from the table will have to be put into
| SVG tile files.
| InsertUser wrote:
| The tile schema being used for the current testing (shortbread)
| doesn't support many languages, but they I think those working
| on this want to support them once the bugs are worked out.
|
| For an example of how this might look see e.g.
| https://americanamap.org which uses OSM data, but doesn't aim
| to be near live like the tiles this thread is about.
| emursebrian wrote:
| This will be great for custom maps.
|
| I am on QGIS 3.30 and many of the street labels at 1:31860 scale
| show up in red and are not aligned correctly.
| maliker wrote:
| It's been fascinating to watch the open source community build
| out vector map tile capabilities. I was doing some web GIS work
| back in roughly 2018, and Google/Apple's streaming vector maps
| performed like magic and something we would have loved to use if
| we could afford it. Shortly thereafter the core tech was
| available in open source, and then there were even free hosted
| solutions. Now our leaflet maps have great vector layers for
| free. Thanks open source!
| NelsonMinar wrote:
| I'm a little surprised it's taken this long for OSM to get
| there, the basic technical pieces were available over a decade
| ago. I don't mean to complain about the free map service, it's
| excellent, and I recognize they focus more on the editing and
| data ownership. Serving is hard and expensive.
|
| Mostly I wonder how much MapBox's dominance for a few years
| disrupted other efforts.
| Firefishy wrote:
| The new stack has some unique feature like the vector tiles
| being minutely updated directly from OSM mapping changes.
|
| There are still issues to fix as it is still only a technical
| preview.
| kibwen wrote:
| Does this reduce the operating costs of hosting OSM-based maps,
| since presumably they require less CPU spent on rendering and
| vectors consume less storage/bandwidth?
| speedgoose wrote:
| Yes, vector tiles are much easier to self host.
|
| You have for example https://protomaps.com/ or
| https://openmaptiles.org/ or https://versatiles.org/ (random
| order).
| hamiltont wrote:
| Yes and No.
|
| No because the official OSM tile layer is heavily subsidized by
| Fastly (EUR720k last I checked) and rendering by AWS (EUR40k)
|
| Yes because technically it would use fewer resources thus
| easier on AWS+Fastly and also easier to self-host
|
| In last risk assessment I read closely(1) OSM noted "If we lost
| [Fastly] sponsorship, we would likely cut off all third-party
| access to the standard tile layer and run a small number of
| Varnish servers."
|
| As I understand it, primary drivers for vectors was not cost
| more improving internationalization, generally enabling client-
| side rendering decisions, and driving a modern toolchain that
| would net multiple follow-on benefits
|
| I'm a bit behind, there is more recent info available at (2)
|
| 1.https://operations.osmfoundation.org/2024/01/25/owg_budget.o.
| .. 2. https://osmfoundation.org/wiki/Finances
| treyd wrote:
| I wonder if it would be feasible to distribute tile data in a
| DHT. There is a single source of truth that could seed the
| DHT and users would share the load of serving the data. It'd
| have to be opt-in on individual nav devices for privacy and
| battery reasons, but anyone running their own OSM proxy would
| have an incentive participate.
| gloflo wrote:
| Way too much latency I am sure.
| Borg3 wrote:
| Yet you forget that tiles based maps are plays very nicely
| even with simplest HTTP caching (even multiple layers of
| them). Compared to vector stuff that needs caches that are
| range requests aware, or some magic block storage.
|
| I somehow prefer to stick to tile based maps because caching,
| easy rendering and I also care about sat images, with cannot
| be vectorized.
|
| I think we need both of those.
| Symbiote wrote:
| These are tile-based maps -- vector tiles, rather than
| raster tiles.
|
| Any caching you do on raster tiles also works here.
| Borg3 wrote:
| Oh okey, So I confused them with PMTiles..
| hyperknot wrote:
| openfreemap.org creator here. Yes, with vector tiles you are
| basically hosting static files, the server has nothing to do,
| except HTTPS encryption. Even gzipping is already done in the
| tiles.
| TrickyFoxy wrote:
| For vector tiles osm.org this is not the case. They should be
| generated on the fly from the database to show mappers the
| current state of the map with minimal delay. Yes, the
| resulting results can be cached like static files, but much
| more work is done on the server.
|
| You can learn more about this in the blog of the developer
| who develops this tile server:
| https://www.openstreetmap.org/user/pnorman/diary/403600
|
| p.s. current link to the demo page:
| https://pnorman.github.io/tilekiln-shortbread-demo
| hyperknot wrote:
| OP asked "Does this reduce the operating costs of hosting
| OSM-based maps".
|
| openstreetmap.org has a very complex setup for real-time
| updates, but in general, hosting OSM-based maps is much
| cheaper with vector tiles.
| sp8962 wrote:
| 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.
| jt_b wrote:
| > 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
|
| this is the first I've seen of these alternative tools
| compared to using
| Tippecanoe(https://github.com/felt/tippecanoe). Are they
| considered to be higher performance?
| sp8962 wrote:
| 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.
| Foofoobar12345 wrote:
| Exciting update! How does the new vector tile system handle
| performance on low-end devices with large datasets?
| sp8962 wrote:
| ... 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.
| boramalper wrote:
| Also see: OpenFreeMap -- free OpenStreetMap vector tile hosting
|
| https://openfreemap.org/
| lxgr wrote:
| Wow, this looks incredibly polished!
|
| Is this based on the same vector tech stack at all, or is it a
| completely parallel development?
| hyperknot wrote:
| No, it's a totally different stack. Have a look at GitHub as
| well, it tells in detail how it's done.
| amai wrote:
| OpenFreeMap is not providing:
|
| - search or geocoding
|
| - route calculation, navigation or directions
|
| - static image generation
|
| - raster tile hosting
|
| - satellite image hosting
|
| - elevation lookup
|
| - custom tile or dataset hosting
|
| https://github.com/hyperknot/openfreemap?tab=readme-ov-file#...
| tetris11 wrote:
| (Low effort comment) I wonder if this means OSMAnd and
| OrganicMaps will now finally team up to deliver the ultimate FOSS
| Map app
| fsflover wrote:
| There is Organic Maps already.
| szszrk wrote:
| And it works really well. The smooth zoom in is amazing.
| sriacha wrote:
| How so?
| tetris11 wrote:
| The fantastic offline routing and metrics of OSMAnd placed
| into a lightweight and snappy OrganicMaps interface would be
| a huge win for me.
| worble wrote:
| At the very least I hope it means they can share map tiles
| between them so I don't have to use gigabytes of space on the
| same map
| sp8962 wrote:
| No it doesn't.
| sp8962 wrote:
| 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).
| PrismCrystal wrote:
| There can be no one ultimate map app because use cases differ.
| For example, OSMAnd has many power-user features that are very
| useful for people who also contribute to OSM, but would only
| clutter the interface of an app for normies.
| gregoriol wrote:
| Is there a tool to capture vector tiles to raster files? Some
| tools like Apple's MapKit don't support vector tiles yet, and it
| could be interesting to use one single map base and be able to
| just generate the raster, instead of having a specific raster
| server
| fingerlocks wrote:
| Apple's MapKit most definitely supports vector tiles, because
| you are given a CGContext to draw with. You just have to
| implement the MVT spec (it's small)
| gregoriol wrote:
| The idea is to use "MapKit" for maps, not to override it and
| draw everything yourself... The fact that it's possible
| doesn't mean it's a good idea.
|
| It is however possible to use Maplibre, Mapbox or some other
| libraries which I think do support vector tiles.
| fingerlocks wrote:
| It's not a lot of work, like at all. And unlike
| mapbox/libre you're are still within UIKit so you can
| leverage all the existing UI tooling on top of your vector
| layers.
|
| It much more performant, ergonomic, and requires no
| external dependencies.
| chris_wot wrote:
| I am absolutely amazed that Apple don't support this yet. I had
| thought mapping was a competitive advantage for them...
| durkie wrote:
| Something like https://github.com/maptiler/tileserver-gl can
| serve raster tiles from a vector tile dataset
| Someone wrote:
| > Imagery should appear much sharper and switching the language
| of the labels should become possible.
|
| I expect that to work sub-optimally. Label dimensions are far
| from guaranteed to stay the same if you change language, and
| label dimensions interact with map layout, even influencing what
| to show.
|
| If your labels grow larger, they may end up covering too much of
| the map or even overlapping. If they grow smaller, users may
| wonder why a city that was omitted before because of space
| constraints doesn't show in the empty space created.
| dheera wrote:
| I hate it when city and street names disappear on Google Maps
| as you zoom in and out. Sometimes a street or business name
| only appears at one particular zoom level and not higher or
| lower. Just show the name of every street damnit. I don't care
| about crowding. Standing at an intersection staring at an
| unlabelled map is a useless map.
| enriquto wrote:
| > Just show the name of every street damnit.
|
| But why? Google Maps is not a navigation aid. Its purpose is
| not to help you know the name of the street you are in. It's
| a tool for paying customers to steer you towards their shops.
| If all you need to do is follow a path towards a certain
| shop, they don't need to show you the names of the streets.
| LeifCarrotson wrote:
| Google Maps is a navigation aid that's also used to sell
| ads.
|
| People don't open the app to look at the ads. They open it
| to navigate, and if it can't be used for that purpose they
| won't open it at all. It is infuriating to me when a
| Wendy's ad is given more visual importance in color and
| size on the app than the actual place I want to find. But
| it doesn't seem to bother a lot of other people. Somewhere
| further in the direction of more advertisements is a point
| where a significant number of normal people will stop using
| Maps as a navigation tool, and somewhere further still is a
| point where more advertisements will become less profitable
| and will be rejected by even the developers. But we're
| nowhere near that point yet.
|
| Until then, I'll keep using a combination of Garmin
| Explore, OsmAnd, and Maps depending on how much I care
| about topo data, traffic status, reviews, search results,
| and ads. I'm setting up an Owntracks so I can replace the
| Timeline data that they're removing customer access to, and
| contributing to OpenStreetMap, but still using Maps.
| astrange wrote:
| Google doesn't really optimize to show you ads. They're a
| monopoly and the voting shares are owned by Larry/Sergey;
| they have no intrinsic motivation to care about anything.
| If you want to be optimization-brained (don't, it's bad for
| you) they optimize for metrics that individual people make
| up and use to get promoted.
|
| They monetize the map other ways, like with the expensive
| API fees, but I wonder if they really care about it.
| Whenever I look at it for a few seconds I see something
| obviously sloppy, like misspelled POI names or people
| adding fake businesses at their apartment.
| PrismCrystal wrote:
| Younger generations are much less likely to navigate by
| comparing a map to the street names at an intersection.
| Instead, people navigate by searching for a particular
| destination and then following the line that the router
| generates.
|
| When Google Maps is a one-size-fits-all product, you can't
| blame them for choosing an approach like this. Fortunately,
| the OSM ecosystem lets you choose (or develop for yourself)
| whatever approach you prefer.
| hackmiester wrote:
| That method just doesn't work in Manhattan, where due to
| buildings, you're lucky if your GPS is working, much less
| the compass to tell you which direction to face.
| PrismCrystal wrote:
| The vast majority of Google Maps users are capable of
| using A-GPS data, they are not reliant on a clear GPS
| satellite signal alone. And Google's A-GPS data for
| Manhattan is extremely detailed. Again, this makes sense
| for a one-size-fits-all product like Google Maps.
| astrange wrote:
| That's not good enough, AGPS doesn't work near
| skyscrapers. The issue isn't that the signal isn't
| "clear", it's that it reflects off the buildings and the
| GPS receiver will get a clear but wrong signal.
|
| To correct this you need something like QZSS or accurate
| models of the buildings to compensate for it.
| PrismCrystal wrote:
| The term "A-GPS" in common practice includes also wifi
| and, as I mentioned, Google's data for this is very
| detailed in Manhattan, too.
| astrange wrote:
| Yeah, it doesn't work for this. I've tried it in the last
| few months and talked to people working on location about
| it out of curiosity. Not in NYC specifically but in other
| cities.
|
| Even short buildings have issues here - if you walk down
| a wide street in Tokyo, which are pretty common and often
| surrounded by 3-4 story buildings, with the map open and
| look at it closely, you will often show up on the other
| side of the street. (Which surprised me, because it's
| literally why QZSS exists.)
|
| Afaik, the issues with WiFi are that if you're traveling
| at any speed there isn't much time to do scans, and the
| position of the WiFi networks themselves isn't clear
| enough because of multipath (reflections), because it is
| crowdsourced from other devices that don't have real
| ground truth locations, and because the other devices
| gathering info are at different heights above ground or
| are indoors.
|
| The main advantage of A-GPS with WiFi is that it starts
| up faster and that it mostly works indoors or when you
| can't see any satellites.
| mycall wrote:
| The correction which Apple and Google are taking is
| anonymous UWB location in a mesh network via Time of
| Flight (ToF), Angle of Arrival (AoA) and Device-to-Device
| communication.
| astrange wrote:
| That is how locations are transmitted for Find My
| Phone/Device, and how relative close-by positioning works
| for AirTags and similar, but it's not used to determine
| absolute locations as far as I know. It would certainly
| be cool if it did that though.
|
| You might be thinking of
| https://en.wikipedia.org/wiki/Differential_GPS.
| mycall wrote:
| 3GPP Release 16 started the UWB location and position
| scope while Release 17 finalized the 5GC capability.
| Perhaps more work is being done there, I haven't been
| tracking it closely lately.
|
| https://www.3gpp.org/technologies/location-and-
| positioning
| tacker2000 wrote:
| Not sure if thats true. I see some people using the blue
| line, but some dont and instead look for street names, etc.
|
| I also dont think that this is the reason that the street
| names are often hidden.
| c0nsumer wrote:
| On a couple recent trips I ran into this when trying to
| figure out what river I was near / crossing. Multiple times I
| basically said "lemme get a better tool for this" and flipped
| to OsmAnd. Google Maps just basically/barely showed there was
| a channel of water and didn't show the name.
| dheera wrote:
| Also not to mention while navigating Google Maps stupidly
| hides all the business names en route. I want to see every
| single business along my route, damnit, so that I know
| where I could possibly go to eat or stop for a rest along
| the way.
|
| The Google Assistant is also the most useless piece of crap
| ever. "OK Google show me all the businesses on the map"
| doesn't work, and neither does "OK Google zoom in" for that
| matter. Most useless UX ever.
| kevincox wrote:
| > Just show the name of every street damnit
|
| I don't know about every street. But if you zoom in all of
| the way then yes, every street more than slightly in the
| viewport should be labeled. I have the same problems with all
| sorts of things like lakes where you need to find the magic
| zoom level and map position that reveals the name.
|
| Some things are understandably harder, I don't necessarily
| need the Country, Province and City in every view of the map.
| But streets and lakes tend to not have much stuff inside of
| them so it seems obvious that when zoomed far in they should
| appear.
| SoftTalker wrote:
| And zoom the label font size with the map size. I'm an old
| guy and cannot read the text on the map. Try to zoom in...
| the map zooms but the text stays the same size. Maddening.
|
| I don't recall offhand whether it's Apple or Google maps that
| do this. Maybe both.
| DidYaWipe wrote:
| Or when you zoom in and the names remain tiny and illegible.
| tacker2000 wrote:
| I also hate it! I dont know why they do it, sometimes i zoom
| in all the way and there is still no street name. Its just
| silly, who is making these design decisions?
|
| The problem is, i keep using maps because google has the best
| POI system/database around, and it will take other apps long
| yo beat it, even apples POIs cant hold up...
| maxerickson wrote:
| The starting case is anyway automatic positioning of the
| labels.
|
| Even on the raster tiles that have been in use for years.
| jayd16 wrote:
| Why would you expect the layout algorithm to be significantly
| different?
| teraflop wrote:
| It's not that the layout algorithm is _different_ , it's that
| the algorithm tries to optimize the positions of text labels
| to get an aesthetically pleasing spacing, while preventing
| them from overlapping each other.
|
| If you keep the label positions the same, but translate the
| text, then the layout will have been computed with the wrong
| bounding boxes, and you will tend to get wrong spacing and
| unintended overlaps.
| Someone wrote:
| > the algorithm tries to optimize the positions of text
| labels
|
| Not only that, deciding whether to show a label at all can
| depend on its size and shape, and if a label deemed
| important becomes larger that can lead to the decision to
| not show some map details (in an ideal world)
| Eduard wrote:
| is there already a live version of this? Because for me, there
| doesn't seem to be an option for activating vector tiles on
| https://www.openstreetmap.org/
| maxerickson wrote:
| See https://community.openstreetmap.org/t/vector-tiles-on-
| osmf-h...
| Eduard wrote:
| thank you very much; on the link provided, I found this demo:
| https://pnorman.github.io/tilekiln-shortbread-demo
|
| https://github.com/pnorman/tilekiln-shortbread-demo
| marklit wrote:
| Sorry, I just added a link to a live demo in the post:
| https://pnorman.github.io/tilekiln-shortbread-demo/
| Tepix wrote:
| This is a very welcome new development! I look forward to even
| better looking maps.
|
| I'm just a bit puzzled by the "my workstation" section :-). There
| doesn't seem to be any relation to the rest of the article, not
| even high system requirements to do the things discussed after
| that.
| zawaideh wrote:
| The other issue is that the arabic font is not rendering
| correctly in the vector version. It's rendering left to right
| (instead of right to left) with characters broken up instead of
| linked.
| sp8962 wrote:
| 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.
| SSLy wrote:
| Indeed, but that is probably not going to help end users of
| apps.
| sp8962 wrote:
| 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.
| lxgr wrote:
| > It is difficult to beat raster tiles in that respect.
|
| Intuitively, why can't the local vector rasterizer do
| whatever the server-side tile rasterizer does, especially
| if both are fully custom?
| wiredfool wrote:
| 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.
| lxgr wrote:
| 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?
|
| That makes sense then, thank you!
| wiredfool wrote:
| 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.
| sp8962 wrote:
| > 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.
| maxerickson wrote:
| It can, it's just that they typically don't, because they
| use an off the shelf data schema for the tiles and a
| library to handle the rendering.
|
| Having the data in tiles also complicates some things
| (where the renderer needs to consider merged tiles to get
| a similar result).
| astrange wrote:
| For Arabic specifically, different users want text to
| render differently, so you'd want to do it on the client
| if you can.
|
| (Some countries use Roman numerals and some use Arabic
| numerals for numbers. And by Arabic numerals I don't mean
| 1-9.)
| rafram wrote:
| All Arabic-speaking countries use Arabic numerals. Some
| use Western Arabic numerals (123) and some use Eastern
| Arabic numerals (123).
|
| Roman numerals are I, V, X, etc.
| dnpls wrote:
| it looks like the selected font doesn't support arabic text,
| producing the disconnected characters.
| timwis wrote:
| Does anyone know if vector tiles could carry adequate data to
| facilitate reverse geocoding (address lookup)? E.g. the polygon
| of a building containing its street address in its metadata. I'm
| surprised I haven't seen that before, as reverse geocoding
| services can get expensive, though I wonder if it's because I've
| misunderstood how vector tiles actually work.
| durkie wrote:
| Yes, they could. You can attach whatever metadata you want to a
| vector tile feature.
| lxgr wrote:
| Possibly, but why would you want to do this client side? This
| seems like the type of operation that makes much more sense in
| "OSM space", not vector graphics space.
| sp8962 wrote:
| 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.
| shpx wrote:
| I can't believe they still haven't added a 2x pixel density
| version of the default map style. It's $CURRENTYEAR and we all
| have high pixel density phones. No one uses 1080p displays
| anymore. The default blurry version makes any page using OSM feel
| amateur.
| Doctor_Fegg wrote:
| Raster tiles hosted at tile.openstreetmap.org are not intended
| for widespread production use, they're principally for mapper
| feedback. If you have a business need for something that
| doesn't look "amateur" you should arguably be using a third
| party OSM-based service or hosting your own tiles.
| Firefishy wrote:
| We don't offer 2x raster tiles because we simply don't have the
| resources to do it while keeping the tiles minutely updated and
| open access. We serve around 60k req/sec on a tiny donation
| backed budget.
|
| The raster tiles are primarily for our OSM mappers to see their
| map changes rendered quickly to improve the feedback loop.
| junaru wrote:
| > No one uses 1080p displays anymore.
|
| I live in a bubble, the post.
| KameltoeLLM wrote:
| > No one uses 1080p displays anymore Ever had to use some
| midrange business laptop, shitpix?
| HumblyTossed wrote:
| How soon before mobile apps can start using these?
| puddingvlaai wrote:
| I'm a bit conflicted with vector tiles. I haven't found a good
| combination of style and tile generator (schema) that provides
| the same level of detail as the original raster tiles provide.
|
| The article has screenshots that very much demonstrate this
| difference. The first screenshot has, for example, a lot of POIs
| (statues, shops, theaters, viewpoints), highways that are
| different when they are bridges, different colors for grass vs
| parks, different line widths for different highways, sports
| fields, building and neighbourhood names, arrows denoting one-way
| streets, building parts, stairs, trees, and a lot more.
|
| The second screenshot has none of that, aside from a single
| trolly station and a single street name (which is also rendered
| incorrectly).
|
| I've tried a lot of vector styles (all openmaptiles styles, the
| base protomaps styles, all mapbox styles) and generators
| (protomaps, openmaptiles, mapbox). None of them come close to the
| amount of detail as the raster OSM tiles while still being as
| readable.
|
| I've never found anyone as bothered with this as I am. Vector
| styles are cool as they zoom and pan very smoothly, and their
| style is fairly easily editable. But, for any map where you
| actually want to see map data instead of using it as a base map
| for your own data, vector maps fall short.
|
| Maybe it is just because of computational limits. I can imagine
| that displaying the same amount of detail as the OSM raster tiles
| would require too many resources: both on the client side and for
| tile generation.
|
| It would be nice if OpenStreetMap would try to mimic their raster
| style closer, instead of providing just another low contrast, low
| detail base map. I hope this release of open vector tiles will
| facilitate more detailed vector maps!
| mycall wrote:
| I've been successful with using
| https://maputnik.github.io/editor in the past for disabling
| lots of features, so I imagine it could do the opposite and
| enable all the layers and features you want to see on a vector
| map.
| puddingvlaai wrote:
| I've tried that, but the openmaptiles spec and protomaps spec
| just don't provide enough details to be able to display a
| detailed map like the OSM raster tiles.
|
| That's not to say that maputnik isn't great; it is! It's an
| awesome frontend to the complex style files.
| maxerickson wrote:
| Some of what is going on is that the software to generate
| continuously updated vector tiles has been the focus, rather
| than fleshing out a style that uses those tiles.
| puddingvlaai wrote:
| That's great and wasn't clear at all from the article. The
| engineering challenge behind that is very much worth a post
| on its own. Must've been no small feat!
| sp8962 wrote:
| 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
| puddingvlaai wrote:
| Ah this is great and super interesting. Thank you!
| serbuvlad wrote:
| I agree with you wholeheartedly. I use a mix of OpenSteetMap
| and Google Maps to get around. I would love to use exclusively
| OSM, but it simply doesn't have as many places catalogued.
|
| I can't describe how much more usable OSM maps are because of
| how many POIs they show. You get a very real sense of the
| physical place just by looking at the map. A park looks
| distinctly like a park. A hospital looks distinctly like a
| hospital.
|
| Google Maps looks a lot better from the perspective of a
| graphic designer, sure. But I usually have to resort to cross-
| referencing the shape of streets/intersection to get my
| bearings. With GM everywhere looks like everywhere else.
| andrepd wrote:
| What was that interlude about the computer's specs lol, I thought
| it was going somewhere but it didn't.
| moffkalast wrote:
| I think what he implies is that he's hosting it locally on
| that, in which case the high specs are a weird flex because the
| demo map runs like absolute molasses for me.
|
| Maybe it's high load or the guy doesn't have much upload speed,
| but it showcases that overzooming low level tiles renders
| really bad square lines when the high detail layers refuse to
| download.
| jkrubin wrote:
| I saw some morecantile/mercantile in the article, so I will plug
| a side project of mine "utiles" for anyone needing tile util(e)s:
| https://github.com/jessekrubin/utiles
|
| Was fun to write and I learned loads!
| orthoxerox wrote:
| One thing I appreciate about the default raster-based maps is how
| snappy they are. Zooming in and out on OSM is much faster than on
| Google/Apple/Yandex/Bing maps. Of course, vector-based maps mean
| I can finally use OSM for countries that use
| Ethiopic/Arabic/Hebrew/Georgian/Armenian/Hanzi/Indic writing
| systems.
| eMPee584 wrote:
| https://marble.kde.org/ has had their own implementation of a
| streaming vectorOSM layer for nine years and I was eagerly
| waiting for something akin to materialize in other OSM map
| applications for quite a while.. Downloading hundreds of megs of
| map data in big whole-country chunks always was a space issue in
| android OSM apps. Very glad a standard is finally being
| established and looking forward to it getting picked up and
| polished.. Great work! : )
| bityard wrote:
| I went looking for the Marble app on Android and it's not in
| the Play store or on f-droid. The link to the Play store from
| the website is a 404. Did they abandon it?
| eMPee584 wrote:
| Sidenote: the most infuriating thing about google maps widgets
| has been the removal of the scale by default. All them
| transportation apps with their embedded map views have been of
| annoyingly limited use for multimodal navigation.. without a
| scale it just leaves me guessing whether a distance can be
| considered walkable .. Then I was flabbergasted when leaflet
| copied this crucial design decision.. yet my efforts to convince
| the leaflet team to reconsider reverting the default (because
| defaults are rarely changed downstream) utterly failed:
| https://github.com/Leaflet/Leaflet/issues/8902 .. awefully
| reminds me of the design trend for thin scrollbars and tiny touch
| targets being enforced in GUIs all over, mostly without an easy
| option even to configure it.. WONTFIX in KDE f.e.
| https://bugs.kde.org/show_bug.cgi?id=416003 come on.. Hopefully
| with AI, we'll soon enter an era of liquid software where
| everything can be dynamically changed at will. Oh the future,
| behold xD
___________________________________________________________________
(page generated 2024-11-19 23:00 UTC)