I dabbled in web-based mapping a couple years ago and found the tech stack to be really quite polished. Starting from a database of features from e.g. OpenStreetMap hosted in a Postgres-based PostGIS map server, and geographical boundaries via special shape files, you can write XML files representing the features you wish to see on each layer of the map (using SQL queries intended for PostGIS), and CSS-like style files representing how the features should look. You then set up a tile server (Apache or nginx or whatever) that generates tiles on demand and performs caching. Finally you use a JavaScript library to provide the "slippy map" that users can drag around.
All of these layers of the tech stack have FOSS implementations; indeed most of the most widely used ones are FOSS. And then there's QGIS (also FOSS) to do most of this in a similar fashion, but offline.
As merely a dabbler having a bit of fun, it's rather excellent I must say. It would be interesting to hear from anyone working in this field professionally as to how the FOSS tools measure up.
QGIS is enormously valuable to those of us who need to do what I would non-authoritatively term "intermediate level geospatial analysis" in jobs that might not have geospatial analysis as part of the official job description, but don't have thousands of dollars available for the ludicrously expensive ArcGIS license.
That is such an absurdly specific but accurate description. I used to manage a site that had a lot of geospatial elements, including various custom maps and obscure (outside of the GIS world) data formats like geotiffs or KML or DTED or the WMM. Coming from a non-GIS background and without the need for an expensive solution like ArcGIS, I have no idea how I would have sanity checked any of it without QGIS
We do a huge amount of very complex analysis and entirely run QGIS. Looked at ArcGIS and decided it wasn't anywhere near worth the money, and getting into their ecosystem at all makes it borderline impossible to interop with e.g. QGIS sensibly.
My current job has pretty low standards for maps in reports, and unfortunately QGIS has a dealbreaker issue: I'd like to just import a basemap, display my data on top, and then export as an image; however, in QGIS the resolution of the basemap scales with the resolution of the export. So, for example, if you want a 300 dpi image, all the city and and street labels (from the basemap) will be microscopic. It's baffling that the software does this, and as a result I have to use ArcMap for these simple maps.
QGIS will, for raster basemaps, fetch the detailed version to get you your high DPI detail but this of course involves stitching together lots of tiles from the basemap's lower zoom levels - which then have small labels. For raster maps which are not labelled, it makes complete sense and produces a much better result than the alternative (picking the "scale based" zoom level and interpolating).
This is kind of the only "right" answer when dealing with raster basemaps. It's either pixellated or going to be rendered "too small" for the zoom level.
Vector basemaps don't have this problem, and QGIS supports them, so that's the way to go if you can get data. QGIS can then render at the required DPI in full clarity but with elements scaled/positioned appropriately.
I was about to firmly disagree, but perhaps my issue is that I've been assuming XYZ tiles were vector. Maybe _some_ are vector, based on the connection? If I'm remembering right, I imported a load of XYZ sources, and then never thought twice about them. I should have been more discerning. I'll look deeper into getting some proper vector basemaps.
> This is kind of the only "right" answer when dealing with raster basemaps.
I believe ArcMap uses rasters (when you choose the simple "add data" feature and one of their pre-selected basemaps), but they still render the labels appropriately when you export.
I've recently started working in this space. Loads of applications in research, Ag tech and environmental science and it's mostly using this tech stack (as well as GeoServer.) Definitely a nice change from my typical ecommerce/saas work. Working with some long term geo/surveyor types and they seem happy with the open source offerings.
It’s crazy to see how much has remained the same, even if so many new things were added. Looks like pretty much all the buildings that existed in 1777 still exist today.
Even crazier to think that at the time the original map was made, pretty much all cities in the US didn’t even exist yet.
The Measure Of All Things is a book about the effort to measure the circumference of the earth to establish the length of the metre, about twenty years after these maps were made. The book goes into a bit of the technology used to reduce errors.
But on further reading, it looks like there was an advance in theodolite design between when these maps were published and the survey for the metre. Wikipedia provides a good rabbit hole.
It's interesting to see how segmented Antwerpen was back in 1777, what the author describes as hedges.
These were usually the result of inheritance, when the land of one owner got split into pieces and each child then got one piece. They got smaller and smaller.
I didn't think that this was already so extreme in 1777, but comparing it to the other maps, only Antwerpen and Brugge seem to be affected.
Nice project, and nice map! I did not know the Ferraris map, it is gorgeous.
It would love to see a tile server of this map, preferably with a switch between the old and the new map.
There is a 'time travel app' for Belgium [1] that includes the Ferraris map, and even older maps.
It's a bit clunky, I like the Dutch topotijdreis (topo-time-travel) [2] a lot more, but it seems like the maps are not as old and not as good, I have to slide to 1898 to get a colored map of Amsterdam.
Modern Google/Apple maps are incredibly low contrast and I don't know why. Seems like they want to have streets and land stand back to make room for features such as pin locations, buisness markings (advertising) or dedicated layers such as traffic.
I really don't get it. Here in Germany, in the last century, "road atlases" were a thing, big maps with great overview and detail maps which were basically at maximum contrast. For examples, see for instance https://duckduckgo.com/?t=ffab&q=autokarte+deutschland&iax=i...
It seems that OSM (OpenStreetMaps) gets this "more right" in some respect, but still it is not the same. Why? Too little confidence of the map makers to highlight the correct things?
The top one is completely unusable if you want to do anything other than drive a car on the highway, in which case it's actually quite good.
(I picked this area specifically because it contains highway, railway, footpaths, water, residential area, industrial area, open fields, forest, and wetland. You wouldn't know, though, if you only looked at the top map. But it's not a location picked to be unfavourable to Google Maps – I sampled a few other places in the world where OSM coverage is likely to be decent, and it's the same story everywhere.)
I really don't get it why Google doesn't show forests at >13 zoom. I've read people claim that this makes the map easier to read. But I can't be the only one who orients himself on a map based on boundaries between forests, residential areas, and fields.
Is there a way to make Goog's turn-by-turn to not be street name based but instead give directions like old timers did using landmark navigation?
At the old farm house, turn left. After going aways down the road, turn right at by the building with the white archways. Take the next left when you get to the statue of the first mayor.
For full flavor, you'd have to include references to landmarks which no longer exist: "if you pass the vacant lot where the old drugstore used to be, turn around, because you've gone too far."
One explanation would be that roads are not the useful information on modern map, you search for you POI or address, and then query an itinerary, and then you have a very contrasty road, the one you need.
I suspect just looking at maps to find your way is a more and more cornered case.
This was indeed a very deliberate choice by Google, and they have been blogging about it since at least 2011[0]. There are quite some blog posts by Google and others discussing the evolution in online maps from the high contrast design focused on roads and cities, to more “fluid” designs where there is a bit more room to show buildings, forests, waterways and other landmarks that are more suited for exploration rather than navigation.
> where there is a bit more room to show buildings, forests, [...]
? What forests and what buildings, though?
The 2009 - 2011 changes are fine, I guess (indeed I don't need the roads that prominently as they were in the 2009 examples), but at some point beyond that they did jump the shark somewhat with their changes.
My personal pet peeve is that at zoom level 14, all distinction between built-up areas and non-built up areas [1] disappears and you're looking at just one indistinct mess of hazy streets on a grey back background and you can't even really tell the shape of a city from looking at that.
Individual buildings only come in at zoom level 17, by which point you're already quite zoomed in, and forests remain stubbornly hidden.
Google has the somewhat better POI integration and traffic information, but when I want to actually look at a map for orienting myself or getting a feel for an area, I much prefer Openstreetmap's style.
[1] At least where I live, the further distinction between forests and non-forested open spaces is rather rudimentary – a few random areas of fields and other open spaces are correctly shown in some sort of ochre at zoom level ≤ 13, but large areas are simply all drawn in green regardless of whether they're actually forests or not.
I find this quite sad and humorous at the same time. Personally, I'm one that loves looking at maps to familiarize myself with street names in an area of interest rather than the specific route the great Map gods of the cloud have decided for me. I tend to not rely on turn by turn navigation, and actually find it quite annoying with its incessant "in 500ft", "in 400ft", "in 300ft" kind of nagging. Being around people that are absolutely dependant on turn-by-turn directions make gives me a laugh though. On a cross country trip where you're on the same major high going West for >1000m doesn't need turn by turn, yet I've been on a trip with someone that had a damn near panic attack because I started driving without the navigation running. Sad they were that stressed about it, but still damn funny
My partner relies completely on navigation assistants, but they didn't exist when I learned to drive, and I never bothered to adopt them. What's funny is that I feel just as stressed out trying to drive with the navigator as my partner does without it! I am so used to having a high-level sense of the route, and knowing the scale of the turns and the roads involved, that I feel confused and disoriented if I try to just blindly follow the directions. I'm not very good at blindly following, either - I can't relate the distances given to a real-world sense of scale, so I frequently miss turns. Really funny how different the mental strategies used to solve the same problem can be.
People being that reliant on turn by turn navigation is not just sad, it's also quite dangerous. Any time the navigation app's instructions are wrong, unclear or simply a bit too late, it is quite likely to cause that kind of driver to make a sudden and unsafe maneuver. Having a general familiarity with your planned route and its surroundings before you put the car in gear goes a long way toward preventing those panicked reactions.
You might enjoy the Mobile Atlas tiles from Thunderforest [0].
I think the low contrast on Google Maps is uniquely ridiculous. You don't have to go all the way to OSM / road atlas. I think Mapbox Streets, Apple Maps (somewhat) and Gaia Topo Lite (my go to) are all perfectly fine maps with roughly the same "feel".
Google Maps contrast is so ridiculous that I have a private app called "Kontrast Maps" that is just the Maps SDK with a high contrast style applied. Me and a friend with a visually impairment get a ton of use out of that. I would love to publish it if it weren't for the insane pricing on Maps iOS SDK.
I'm also disappointed enabling "High Contrast" in Apple operating systems doesn't apply a high contrast maps style. Seems like a super obvious accessibility feature.
My father travelled a lot for business. So much so that he had a massive map covering a wall in our garage. Before heading out he'd put Blu Tack on the various places he intended to visit and planned out the route he'd take. This required a very high contrast representation of roads to assist him in finding routes; especially given he couldn't magnify the map to focus his attention.
Today, people tend use maps differently, they generally use the map to find POIs (with the assistance of search) and then just ask the computer to tell them how to get there (using various prompts). So, it makes sense that the emphasis is no longer on the streets, but the things that happen to be on those streets.
In some respects, the map is an outdated form for data visualisation. It retains usefulness (in part) because automatic routing remains imperfect (especially for walking in urban environments). However, in time these imperfections will be corrected and I suspect maps will be relegated to niche applications and 'advanced' tabs.
Road atlases were the same in Spain. I think the reason is that they are not interactive, that's the all the zoom level you are going to get and so they are extremely dense with information.
I think that for interactive use google maps are way better, they avoid information overload by presenting a very schematic representation. Old road atlases look like versions of Where's Waldo?.
Cartographic generalization is an AI-complete problem. It is doable for a human to decide what to show or not, in order to get a useful map without too much clutter. It is much harder to program a computer to do it. It is very tempting to turn down contrast to make a cluttered map less "loud".
On that note, one thing I've wanted to do for quite some time is an application that would allow you to open an image file or a set of image files with a particular style of map and it would try to replicate that style with OSM data. Ideally emitting that style in a Mapserver mapfile, or a Mapnik style file, or whatever. If you prefer German-style road atlases, you should be able to have them with OSM data. Doing such things by hand seems incredibly tedious, though.
I've noticed on Ordnance Survey's online maps, the contrast seems lower when printing caps of the 1:25K maps (I take custom paper versions of planned routes out with me, in case both my own nav and my tech options fail) from the new version of their online offering (which us hold-outs have recently been force upgraded to). Though it doesn't look noticeably different on-screen.
I really miss poring over big sheets of paper to find nice routes to cycle over... Especially in France, the Michelin 200.000 maps are unrivaled to not only find your way, but also have a good feel how the road and the landscape looks like. [1].
These Michelin maps have a great feature I've not seen elsewhere: traffic intensity is rendered with color (white=quiet, red=busy) and road-width is rendered as width, binned at a few standard widths. I would love to see that on openstreetmap.
Extra anecdata in case the creator is reading: sliders failed for me on Android Chrome this morning. I made no effort to check if this was due to a script failing to load or some other bug.
The JS script that the author is using relies on listening to both mousedown and touchstart events, etc. It isn't clear to me why Android has a problem with that, but I wonder if switching to listening only for pointer events [1] would fix things.
I've always been fascinated by old cartography.
How did they even have such precision? Which tools did they have? And how did they store the information?
they usually used triangulation, the same as today. they select an line as the startimg point and measure it exactly as possible(doesn't need to be long) and then you can calculate the rest with the measured angles of the area you want to measure. The rest is replicating it on paper with the required factor.
You might find the retriangulation of Britain in the 1930s and 40s interesting [1]. A network of ~6,500 triangulation pillars (trig points) were built across the country, each of which were in line of sight of at least two other pillars. The pillars each have a mounting point for a theodolite, to allow their position to be calculated from the relative angle and elevation of other visible trig points.
They are often on the top of hills or mountains and so have a warm place in my heart from signifying the high-point of many a hike.
Just this morning I finished watching a tutorial on setting up qgis, installing plugins and building a multi-layer map of Mumbai. Very much recommended for anyone looking into GIS https://youtu.be/jgbTosOPU-U
Several of the original maps have some added topology on them, and I think a simplified hill shade could help pop the new ones in a similar manner. You can put it on with something like 90% transparency and get a bit of a pop to add more depth to it. I used to do this back when I still made paper maps, but it should work just as well in a totally digital format.
Edit: On the github readme the author addresses this some. General elevation data isn't in OSM, so it was deemed out of scope for this project.
The datasets are out there, and it's totally possible to do in QGIS. I've done it for Ireland so that I had hillshade on my personal cycling friendly maps.
You just need a DEM model of the area of interest and run a hillshade operation on it. There are a couple of decent DEM datasets, SRTM and Gebco are two that I've run across.
Nice! The rendering is more polished than what I did a few years ago in another similar project: apply CycleGAN style transfer on Google Maps / OpenStreetMap tiles to redraw them interactively as old hand-drawn maps https://github.com/nathanvogel/deepmaps
Side note: I love this style of "artwork". I also enjoy old books with paintings, older maps and whatnot and can look at them for hours.
Maybe it's because I work in print media and know how fast and good modern tools are, so I can estimate (and value) how complicated it was to create all the graphics in former times.
So: Great project to bring back the old style for modern data.
There needs to be an icon set for gallows, gibbets, witch pyres, and
dragon lairs and for coastal areas, sea monsters, whirlpools,
mermaids, treasure, and of course an edge of the flat world.
All of these layers of the tech stack have FOSS implementations; indeed most of the most widely used ones are FOSS. And then there's QGIS (also FOSS) to do most of this in a similar fashion, but offline.
As merely a dabbler having a bit of fun, it's rather excellent I must say. It would be interesting to hear from anyone working in this field professionally as to how the FOSS tools measure up.