Ever needed to simplify street networks? I did. And it is a pain. So we joined forces with @anavybor and @JamesGaboardi and wrote an algorithm that does that for us. And can do for you, as it is available as a Python package called `neatnet`.
Here's a short blog about it - https://martinfleischmann.net/simplification-of-street-networks/
And here's, not so short preprint - https://arxiv.org/abs/2504.16198
But you probably want the package. That is here - https://uscuni.org/neatnet.
Happy coding!
I have been working with street networks for a long time. My first analysis will date probably back to 2017 or so. Most of those focused on the same aspect - understanding the morphology. Yet, practically none of the networks I was able to obtain reflected morphology directly. Rather, they captured transportation networks, with all the detailed intersections, every tiny roundabout, slipway, double carriageway, and so on. Which is pretty annoying when you are interested in a representation of space, not of traffic lines.
Your feedback matters! If you’ve read Geocomputation with Python, consider writing a review on Amazon or Goodreads, etc.
https://www.amazon.com/Geocomputation-Python-Chapman-Hall-CRC/dp/1032460652/
https://www.goodreads.com/book/show/218000479-geocomputation-with-python
Thanks for your support! 🌍📖
"Encode #spatial data as #topology in #Python!
With #topojson it is possible to reduce the size of your spatial data. Mostly by orders of magnitude."
Trying unsucessfully to reproduce this #leafmap example :(
https://leafmap.org/maplibre/globe_control/#import-library
https://www.youtube.com/watch?v=D2bdwLkU1KQ
UPDATE: Different computer... different result...
🚀 New preprint! "Spatial Data Science Languages: Commonalities and Needs" 🌍
Exploring challenges & insights from #Rstats #Python & #JuliaLang for spatial data handling—geodetic coords, data cubes, and more!
🔗 Read here: https://arxiv.org/html/2503.16686v1
Finally a new #Shapely feature release! 🎉
Shapely 2.1.0 highlights include initial support for geometries with M or ZM values, functionality for coverage validation and simplification, and a set of other new top-level functions.
For a full overview, see https://shapely.readthedocs.io/en/latest/release/2.x.html#version-2-1-0
"Spatial Data Science Languages: commonalities and needs" - that a preprint 11(!) of us wrote together as one of many outcomes of two workshops held in Münster (2023) and in Prague (2024). It summarised where we are, what we share between R, Python and Julia, what are the common challenges, lessons and recommendations - https://arxiv.org/abs/2503.16686
Big thanks belongs especially to @edzer who kickstarted the whole initiative! And to all the others who participated!
Recent workshops brought together several developers, educators and users of software packages extending popular languages for spatial data handling, with a primary focus on R, Python and Julia. Common challenges discussed included handling of spatial or spatio-temporal support, geodetic coordinates, in-memory vector data formats, data cubes, inter-package dependencies, packaging upstream libraries, differences in habits or conventions between the GIS and physical modelling communities, and statistical models. The following set of insights have been formulated: (i) considering software problems across data science language silos helps to understand and standardise analysis approaches, also outside the domain of formal standardisation bodies; (ii) whether attribute variables have block or point support, and whether they are spatially intensive or extensive has consequences for permitted operations, and hence for software implementing those; (iii) handling geometries on the sphere rather than on the flat plane requires modifications to the logic of {\em simple features}, (iv) managing communities and fostering diversity is a necessary, on-going effort, and (v) tools for cross-language development need more attention and support.