A visual exploration of the spatial patterns in the endings of German town and village names.
See the live version at http://truth-and-beauty.net/experiments/ach-ingen-zell
I picked the most interesting suffixes from https://de.wikipedia.org/wiki/Ortsname and cross-referenced them with a list of place names from geonames. Please note that the approach is fairly naive: I don’t test for syllables but only match the string ending (i.e. -ach matches Kirchbach).
Yet, it's a dataset I always found interesting to explore and some of the maps are already quite interesting; plus, this quick experiment gave me the opportunity to play a bit with a few new tools and libraries I wanted to learn more about.
Run
npm install
to install all required node.js packages
Run
npm run dev
to build a development version and serve it from http://localhost:8080/
Run
npm run deploy
to build a deployment version into the build directory, which can be uploaded to a normal web server, no server side scripts or settings re required to run the application.
- Slovenian adaptation
- Romanian version
- -tation (Antarctica version!)
- US version
- Belarus version
- Czech version
- Interactive version on OSM data, various countries
- Switzerland/Interactive version in datablog
- Remix using R
- Dutch version, based on above R remix
- To make the original csv file more manageable and compact, I added some headers to the file (based on the readme.txt. I then proceeded to filter the data to include only the place types and columns I need with the useful csvkit utility, like this:
in2csv DE.txt --format csv -d \t | csvgrep -c feature_class -m "P" | csvcut -c name,latitude,longitude > placenames_de.tsv
This sequence of commands
- reads the csv file
- filters for all rows with a “P” as “feature_class”
- keeps only the columns name, latitude and longitude
- and stores the result in “placenames_de.tsv”
This is my first project using webpack as a build tool, so if you have any ideas on how to improve, let me know.
This project uses babel to compile ES2015 (the first step towards a revamped JavaScript). While I really enjoy coffeescript’s conciseness, ES2015 seems to provide a saner foundation for larger projects.
I use the new modularized version of d3 with the wonderful new color scales and the lovely h3-hexbin plugin which made it a breeze to create the hexmaps.
React provides a clean and efficient way to structure and render web applications. As demonstrated in this small example, it can even replace d3 as an SVG rendering tool. React is pretty great in rendering complex nested DOM trees or UIs, but it seems a bit harder to develop very fluid, animated interfaces.
The ways d3 and react handle interaction and animation are quite different, so, basically, one has to decide who is in the driver’s seat:
- In case of react, you will use d3 only for the scales, utilities, layouts, … but not the d3 event handlers or enter-update-exit lifecycle (as done in this example).
- Alternatively, you can use react only to render the container and static parts of the data visualization, and use normal d3 approaches to fill them with dynamic content in the componentDidMount/componentDidUpdate handlers. (However, then you lose a lot of the benefits coming with react.)
Along with ES2015 comes a clearly defined way to specify internal and external script dependencies. For instance, the once monolithic d3 library is currently being split up into modules, which allows to install independent parts of the library using e.g. npm and declare a dependency on them in your scripts (e.g. import d3_scale from 'd3-scale’;). Webpack will pick these dependencies up and bundle all (and only) the required code into your script.
This was just a quick experiment and excursion of mine into a few techniques I wanted to explore. I hope some of these are interesting to you, too — let me know if you have any thoughts or questions!