Hacker Newsnew | past | comments | ask | show | jobs | submit | puddingvlaai's commentslogin

This could use an upgrade. Combining teslausb [1] for video retrieval and teslamate [2] for GPX retrieval, you could probably make this an automatic pipeline. Add in some "excluded locations" and I could see this as a full solution.

[1] https://github.com/marcone/teslausb

[2] https://github.com/teslamate-org/teslamate


Heh, "they should use a computer to emulate the storage" was my first thought when this was posted, didn't even check to see if anyone had done it yet. :)


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!


You are basically right. But your framing might be slightly off. The primary advantage in vector tiles for whoever is providing the map is not the small benefits of greater sharpness or flexibility in styling. It's the vast decrease in compute required. Maintaining the infrastructure to generate up to date raster tiles is a pretty serious undertaking.

I once spent a lot of time developing this very detailed style for planning cycle tours: https://stevebennett.me/2015/01/14/cycletour-org-a-better-ma...

I've tried a few times over the years to replicate it using vector tiles. It's pretty challenging to load enough detail into the tiles without hitting the size limits, and the default Mapbox tiles don't containing anything like enough information.

There are workarounds with vector tiles that raster tiles don't have though, like the ability to turn on/off different layers, while still retaining legibility (because labels can still be aware of what is underneath them).


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.


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!


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


Ah this is great and super interesting. Thank you!


I built a fork of OpenrailwayMap (original at https://www.openrailwaymap.org, vector styles at https://openrailwaymap.fly.dev).

The style was built to match the look of the original raster tiles closely, although I added many more interactivity features in the vector variant.

Is is interesting from a style/tile design perspective that the performance tradeoffs choices become very different how and where the tiles are rendered. This is obvious, but it has effects on what is possible on the server / clients visually as well.


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.


Lack of data in OSM is a very different issue from what is being discussed here.


Obviously. I just brought it up to explain why I use both OSM and Google Maps.


I completely mirror your thoughts. I have spent a fair while trying to bend vector maps into being as good as openstreetmap.org's default style (which in my opinion is just Pure Bliss) and have not managed to find anything workable enough, where you can't notice the loss of detail within 2 minutes of playing with it.

Which is a real pity. I'm optimistic that someone will solve it eventually.


I agree with you, but I go one step further: I am disappointed by OSM raster tiles and especially Google's digital tiles because even they show barely enough information, if you compare them to old style printed street directories. I think they also have a tendency to avoid crowding by omitting important things in busy spaces and showing useless things in empty spaces, whereas the correct thing to do is to show the important things in the busy spaces precisely to indicate that they're busy spaces. And I think there are better things that can be done than just showing trivia if you consider the local area (e.g. a private tennis court might be better off not shown in especially if there's not a great density of mapped objects, but perhaps it's relevant at a resort).

But that's a lot of work, and whereas it's easy to add extra trivia to OSM it's much harder to add extra detail to tiles.


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.


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.


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.


Look into Planetiler [1] (which OP uses for tile generation). It supports downloading regions that are listed on Geofabrik [2] and converting them to mbtiles or pmtiles. Geofabrik has separate extracts for all US states, for example. If you need to extract an even smaller area from that result, GDAL has support for mbtiles so you could use gdalwarp [3] to extract a new mbtiles file out of it using bounds.

Another option is to use the extract functionality in pmtiles [4] to extract your area of interest from their daily full-planet pmtiles builds. You can then statically host that file and use that in your client with one of their client libraries.

[1] https://github.com/onthegomap/planetiler

[2] https://download.geofabrik.de/

[3] https://gdal.org/en/latest/programs/gdalwarp.html

[4] https://docs.protomaps.com/pmtiles/cli#extract


Look into Planetiler [1]. It's a resource-efficient and easy to setup project to generate mbtiles or pmtiles from OSM pbf files, which are free to download from Geofabrik. It uses the openmaptiles spec for the result files and you can also generate some custom tiles by writing yaml (or forking the java source).

Protomaps also provides daily updated full-planet pmtiles [2], from which you can create a pmtiles extract using its CLI.

[1] https://github.com/onthegomap/planetiler [2] https://docs.protomaps.com/basemaps/downloads


Instead of looking up the commit hash in your reflog, you could also just create a branch on that commit and refer to the commit with the branch name.


We played infinite variations of this game when I was a member or leader at our youth movement in Belgium. (I don't think such a thing exists in the US?)

Some examples:

A battleship variant: each team first their his ships in a battleship field. Then, when a player can reach the other team's camp without getting tagged, they can shoot one shot into the field of the other team.

A Stratego variant: every team gets his own stack of cards which represent the different players of Stratego, the board game. Players take a card before leaving their camp. If they are tagged, or tag someone, they show their card to the other person. The winner according to the Stratego rules wins the card of the other person, and the loser must go back to their camp for another card.

Some more games with paint, animal cards, ...

Lot of good memories from that time.


Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: