Map Vectorizer – Map polygon and feature extractor
github.com
github.com
These are nice to have for researchers, but the real purpose of collecting this is, just as you note, to unlock the hidden historical geospatial data in textual materials. Once we've got all those names of places, their addresses, their lat/lon coordinates, and their timeframes of existence, we can start to search through texts to find linkages. Old city directories (they're basically books of ghosts) start to show you who lived and worked where [1] (and in the process starts to get you more names you can associate with these places), address matches in historical newspapers start to show you what happened in these places, and the maps start to become this geospatial backbone to traverse across tons of different datasets.
The Vectorizer is so freaking cool for so many reasons, but mostly because it's going to let us actually get through these insurance atlases to collect this data before we all die (one of our favorites is the 1854 William Perris Atlas [2][3] but it took nearly 3 years to actually get through the 64,000+ buildings in Manhattan south of 42nd st) so we can start doing this kind of querying with it. The real geniuses behind all this, our Geospatial Librarian Matt Knutzen and the team at Topomancy, have been working on an experimental gazetteer [4] so that we'll finally have this as a public web service for people to hack on all these places as we collect and conflate them. Give us a few months...
In the meantime, sign up for the Open Historical Maps project listserv [5] that some of the OSM crew is working on (including the geniuses at Topomancy).
Also, this came out of a historical geospatial hack day [5] we threw a few months back, which you should check out if you want to play around with some of our data sources for this kind of work or for building something else out of historical NYC's geospatial footprint.
[1]: http://andrewxhill.github.io/cartodb-examples/scroll-story/b... [2]: http://maps.nypl.org/warper/layers/861 Tileserver, please forgive me for linking to you [3]: http://aaronland.info/nypl-perris/ YEAH SHAPEFILES! [4]: http://vimeopro.com/openstreetmapus/state-of-the-map-us-2013... Schuyler Earle's presentation on their version of historical gazetteer they're building for the Library of Congress at State of The Map US 2013 [5]: http://www.nypl.org/blog/2013/07/12/maphack-hacking-nycs-pas...
Even just something as simple as showing an OSM with all the historical election districts / assembly districts over time for each census/election as map layers would visually convey to someone looking at an address what would otherwise take a decent amount of time to look up.
The NYC Dept. of Records has all the tax lot photos from the 1940 and 1980 canvas, so you could even build up a historical "street view" for the 5 boroughs. I've always found it annoying that they keep this data locked up and charge a decent sum for each photo. It is something that a decent microfilm scanner could make quick work of, but I don't know if they have plans to liberate all of that image data as part of the open data efforts.
I've been working on something similar recently using OpenCV (though haven't done much on it yet). My use case is to find paths through electrical schematics. I figured my problem was close to map vectorization so I searched around for an existing library in that space but didn't have any luck.
Will be interesting to see how they've approached it and what sort of results I could get using their library.
We do welcome input and merge requests to improve the tool!
Thank you NYPL!
We, however are far more lenient (mostly because we can't afford to build a time machine to map the past ourselves).
On the other hand, Mike Migurski's Green Means Go [1] project is fantastic for figuring out where batch imports into OSM will be greeted with confetti and parades for filling out parts of the US without enough coverage to warrant anti-import protectionism.
http://wiki.openstreetmap.org/wiki/Import
But most of that's importing already digitised info. Relevant to this topic, vectorising from images, there seems to be renewed work on autotracing from satellite imagery coming to the iD editor:
http://www.mapbox.com/blog/user-friendly-guided-feature-extr...
edit: just noticed you linked to that elsewhere in this thread.
That being said, thank you for throwing this up for the uninitiated. Some of the emails to the OSM-main and OSM-US list were hilarious, like people populating entire country-worth datasets. Boy, did people yell at them.
http://wiki.openstreetmap.org/wiki/Washington_DC/DCGIS_impor...
I think I'll give it a whirl on some old 60's fenceline maps I have around.
And while not mapping, John Resig's Ukiyo-e [2] project is one of the coolest projects I've seen in the digital cultural heritage space in some time. He's been applying image recognition to these incredible Japanese woodblock prints from museums, galleries, dealers, universities and libraries all around the world. Because these things are prints, there could be hundreds of prints from the same block master all around the world, but because the expertise in the field is so divergent, the cataloging practices are really inconsistent. Different institutions might call artists by totally different names (or think a print is by totally different artists). So he built a search-by-image search engine of hundreds of thousands of Ukiyo-e that finds and reunifies prints totally independently of their metadata. Which is cool when you find 5-10 of the same print in places around the world. But it's cooler when it matches 2 prints with totally different artists and publishers and dates because at some point after the first print was made, someone bought the block master, cut out the face and replaced it with another, then did the same for the signature [3][4].
Actually, The Vectorizer owes a big debt of gratitude to John and his brother Mike. Mike Resig is a geographer and was the first to show us a process for how this kind of automated identification is possible.
[1]: http://www.mapbox.com/blog/user-friendly-guided-feature-extr... [2]: http://ukiyo-e.org [3]: http://ukiyo-e.org/image/met/DP134583 [4]: http://ukiyo-e.org/image/mfa/sc214530
A naive version is also fairly easy to build up from existing tools (e.g. OpenCV), but getting it to work reliably is often a pain. Even with the best tools, this sort of thing requires a lot of manual QC. It still greatly speeds things up, though!