The Muninn Project - Racket

Print your own Battlefield

m4farrel — Fri, 27 Mar 2015 15:11:43 +0000

The Muninn Project aims to programmatically recreate scenes of historical events using Linked Open Data - and with the ever-increasing availability of high-quality 3D printers, we are motivated to 3D-print these scenes. In this particular post, we will talk about how to 3D-print a battlefield: the trenches of Vimy Ridge. We believe that 3D-printed models of battlefields, such as the trenches of Vimy Ridge, could be quite useful to archeologists & other individuals studying past historical events, namely the Battle of Vimy Ridge. We will discuss how to retrieve 90m-resolution elevation data inside a bounding box from the Shuttle Radar Topography Mission (SRTM), how to scale & project it with the Geospatial Data Abstraction Library (GDAL) and also how to convert it to an STL file that can be 3D-printed; we will also discuss how to retrieve lists of trench coordinates from the Muninn Project's SPARQL server, and how to extrude trenches on our model of Vimy Ridge before 3D-printing it. Lastly, we will discuss issues regarding the size & resolution of our model of Vimy Ridge and suggest how we might improve the quality of our model in the future. Thanks to Lawrence Willett for letting us use his 3D printer.

In order to 3D-print a battlefield, we first need to determine its bounding box. Currently, the Muninn Project's SPARQL server provides lists of trench coordinates for Vimy Ridge contained in (2.70251452076269, 50.0620220454661, 2.75071474125368, 50.0722188449797). We chose to 3D-print a model of the trenches of Vimy Ridge that lie inside of this bounding box.

After determining the bounding box for our battlefield, we need to retrieve the elevation data inside of it. We've built software - written in a modern descendant of Scheme known as Racket - that allows us a retrieve raster images of elevation data inside of bounding boxes. Our software also allows us to UTM-project and scale our raster images to 1m resolution, necessary in order for us to extrude trenches on a 3D-printable model of our battlefield; we use GDAL behind the scenes. Here is a projected & scaled raster image of elevation data for our model of the trenches of Vimy Ridge:

We then create a raster image of trench data for Vimy Ridge with the same origin, dimensions, resolution and projection as our raster image of elevation data. First, we retrieve lists of trench coordinates inside of our bounding box using the Muninn Project's SPARQL server; as mentioned, currently all of the trench data that we have for Vimy Ridge is contained within the bounding box we chose to use for our model. Before getting lists of trench coordinates, we first find all known World War 1 objects inside of this bounding box:

SELECT DISTINCT ?thing ?state {
  ?thing <http://geovocab.org/geometry#geometry> ?geoma .
  ?thing <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
         <http://rdf.muninn-project.org/ontologies/military#MilitaryTrench> .
  ?geoma <http://linkedgeodata.org/ontology/posSeq> ?SEQ .
  ?SEQ <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
       <http://www.w3.org/1999/02/22-rdf-syntax-ns#Seq> .
  ?SEQ ?List ?node .
  ?node <http://www.w3.org/2003/01/geo/wgs84_pos#lat> ?LAT .
  ?node <http://www.w3.org/2003/01/geo/wgs84_pos#long> ?LONG .
  OPTIONAL { ?thing <http://rdf.muninn-project.org/ontologies/graves#hasState> ?state . }
  FILTER (?LAT  < 50.0722188449797 && ?LAT  > 50.0620220454661)
  FILTER (?LONG < 2.75071474125368 && ?LONG > 2.70251452076269)
}

Then, we find lists of trench coordinates for each trench object, after filtering out known WW1 objects that are not trenches. For each trench object, we execute the following SPARQL query, giving us a list of trench coordinates:

SELECT ?List ?LAT ?LONG {
  <trench> <http://geovocab.org/geometry#geometry> ?geoma .
  <trench> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
           <http://rdf.muninn-project.org/ontologies/military#MilitaryTrench> .
  ?geoma <http://linkedgeodata.org/ontology/posSeq> ?SEQ .
  ?SEQ <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
       <http://www.w3.org/1999/02/22-rdf-syntax-ns#Seq> .
  ?SEQ ?List ?node .
  ?node <http://www.w3.org/2003/01/geo/wgs84_pos#lat> ?LAT .
  ?node <http://www.w3.org/2003/01/geo/wgs84_pos#long> ?LONG .
  FILTER (?LAT  < 50.0722188449797 && ?LAT  > 50.0620220454661)
  FILTER (?LONG < 2.75071474125368 && ?LONG > 2.70251452076269)
} ORDER BY ASC(?List)

where trench is the Uniform Resource Identifer (URI) for the trench object.

We then UTM-project each list of trench coordinates, and afterwards sort them by finding the shortest path between the two coordinates closest and farthest from the origin in each list. Finally, we are to produce a raster image of our trench data for Vimy Ridge: for each projected & sorted list of trench coordinates we create a "drawing pen", set its line-width to the desired the width of our trenches, set the grayscale value of its colour to the desired depth of our trenches and then draw lines between each sliding pair of coordinates in each list of coordinates, saving our drawing as a raster image:

Once we have projected & scaled raster images for both our elevation data and trench data, we then create a trench-extruded terrain mesh in Blender, which we can export to an STL file for 3D-printing. Secondly, we create a plane mesh with the same dimensions as our raster images, subdividing it so that it has the same resolution as our raster images as well. Thirdly, we add a displace modifier to set the height values of each point on our plane to each corresponding grayscale colour value of pixels on our elevation raster image. Lastly, we add another displace modifier, extruding trenches with the raster of image of trench data that we created:

Finally, we export the trench-extruded terrain mesh that we created as an STL file, which we send to the 3D printer:

We were able to produce a 3D-printed model of the trenches of Vimy Ridge with comparable quality & resolution to that of our digital 3D model. In the future, we'd like to increase the size of our 3D-printed model to include more of Vimy Ridge, namely the ridge itself. This may prove somewhat difficult because the polygon count of our trenched-extruded terrain mesh in Blender, and hence our STL file, might grow too high to view, export and print; in other words, we might hit our current hardware limitations when we try to 3D-print a larger battlefield. Though, we might be able to overcome these potential limitations by either (a) increasing our computing power (b) using Blender as a library to avoid the need to render our trench-extruded terrain mesh in Blender before exporting it or by (c) printing separate parts of our model and gluing them together afterwards.

We encourage you to try printing your own battlefield using the methods & software provide in this blog post - let us know how you made out! Stay tuned for more information on 3D-printing your own historical battlefields.

P.S. This is what it looks like when 3D-printing fails:

Language English

Tags:

3D Printing

Vimy Ridge

Trenches

Elevation

Retrieving Historical Photos of Film Stars using DBpedia

m4farrel — Thu, 29 Jan 2015 14:23:20 +0000

This is a follow-up to the previous blog post on retrieving historical art from the Rijksmuseum. Like historical art, film star photos inform us about politics and human culture at particular times throughout history - but there are so many film star photos that it becomes difficult to devote sufficient attention to each individual photo. We can use DBpedia to retrieve historical photos of film stars and display them in our statistically generated scenes of historical events. We'll display both film star photos and historical art that best fit the contexts of our statistically generated scenes - and use the context of the scenes that they are placed in to interpret them for their historical significance.

As an example, let’s look at film stars who were active around the time that Anne Frank was alive. We'll look at film stars who became active 1900-1945, even though Anne Frank was born in 1929. Anne Frank pasted photos of film stars on her wall who were active before she was born, such as Greta Garbo who became active in 1920. Here’s a SPARQL query to retrieve film stars who were active during that time period:

PREFIX wordnet: <http://www.w3.org/2006/03/wn/wn20/instances/>

SELECT DISTINCT ?actor ?thumb ?start {
{
    ?actor dbpprop:wordnet_type wordnet:synset-actor-noun-1 .
} UNION {
    ?actor dbpedia-owl:occupation dbpedia:Actor .
}
?actor dbpedia-owl:thumbnail ?thumb .
?actor dbpedia-owl:activeYearsStartYear ?start .
FILTER (?start > "1900-01-01"^^xsd:date)
FILTER (?start < "1945-01-01"^^xsd:date)
FILTER EXISTS {
    {
      ?film dbpedia-owl:starring ?actor .
    } UNION {
      ?film dbpprop:starring ?actor .
    }
}
}

We can execute that SPARQL query and retrieve the results by sending a GET request to DBpedia’s SPARQL endpoint:

http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&for...???

Note: we’d set the query parameter to be our SPARQL query.

Here's a sample of the results that are returned after executing the SPARQL query:

actor	thumb	start
http://dbpedia.org/resource/Amparo_Rivelles	http://commons.wikimedia.org/wiki/Special:FilePath/Amparo_Rivelles.jpg?width=300	"1942+02:00"^^<http://www.w3.org/2001/XMLSchema#gYear>
http://dbpedia.org/resource/Art_Acord	http://commons.wikimedia.org/wiki/Special:FilePath/Art_Acord_Kephren_1917.jpg?width=300	"1912+02:00"^^<http://www.w3.org/2001/XMLSchema#gYear>
http://dbpedia.org/resource/Bobby_Burns	http://commons.wikimedia.org/wiki/Special:FilePath/Cuckoo_Comedies_(1919)_-_Ad_1.jpg?width=300	"1908+02:00"^^<http://www.w3.org/2001/XMLSchema#gYear>
...	...	...

There are too many results to list in the table above. So, how many film stars were active during that time period?

> (film-stars/count 1900 1945)

1633

Let’s have a look at a sample of a film star photo that we would place in our statistically generated scenes of historical events:

> (film-stars/sample 1900 1945)

There are a couple of problems with retrieving film star photos using DBpedia.

One problem is that some photos of film stars are modern, and would look out of place in our exhibits. We could check if the photos are greyscale before displaying them, but this might not always be effective. For example, this photo of Philip Ober was taken in 1950, even though we only want film stars who were active between 1900 - 1945; we wouldn't want photos that were taken after the date when a particular historical scene that we are recreating takes place. There is no property that tells us when the photo of film star was taken.

Another problem is that there isn’t information available about when some film stars were active, e.g. Sonja Henie as mentioned in this article from the Anne Frank House; this means that they are not included in the result of our SPARQL query. It might be possible to use the release dates of the films that actors/actresses starred in as a proxy for information on when they were active.

We've made a Unity3d picture frame asset that retrieves a random film star photo from DBpedia and displays it when the scene that it is placed in is played. The asset is available in this repository. Stay tuned for more on statistically generating historical scenes!

Language English

Tags:

Retrieving Historical Art from the Rijksmuseum

m4farrel — Mon, 19 Jan 2015 14:02:18 +0000

The Muninn Project aims to statistically recreate scenes of historical events using Linked Open Data. Historical art is rich with information important to the study of politics and human culture - but there is so much historical art to examine that it becomes difficult to devote sufficient attention to each individual piece of art. So, how might we resolve this problem of "information overload"? If we statistically recreate scenes of historical events, and retrieve relevant art to display in them, we argue that analysis of the art becomes easier with the additional historical context provided by the scene. Let’s try this.

The Rijksmuseum is a national historical art museum located in Amsterdam. They provide a public API for retrieving art objects in their collection, which you can read more about here. There’s close to one million art objects made available by the Rijksmuseum. We can narrow down our search for historical art: we’ll try to sample only the art that best fits the context of our recreated historical scenes.

As an example, we’ll retrieve art from the Rijksmuseum produced between 1845 and 1945 to display in a scene of a historical event that took place during that time period. We could send a GET request with the following URL to retrieve the first piece of art that satisfies this constraint:

https://www.rijksmuseum.nl/api/en/collection?key=WfTGhlrw&q=&yearfrom=18...

Note that: we’ve also restricted the type of art that we retrieve; we’re only retrieving prints, even though the Rijksmuseum also provides photos. We’ll begin to look at historical photos to display in our scenes in a future blog post. The Rijksmuseum may or may not be the best source for photos, though they certainly provide very high quality images of prints that are important to Dutch history. Calls to the Rijksmuseum API return a JSON object, listing the titles of art that match our search parameters, and links to images of them.

Let’s look at the art objects that match our search parameters. You might be wondering, how many of the Rijkmuseum’s art objects were produced between these years?

> (rijksmuseum/count 1845 1945)

7622

There is a fair volume of historical art to examine between those years. So, what might a sample of that art look like?

> (rijksmuseum/sample 1845 1945)

This sample of historical art is of Japanese origin. Most of the Rijkmuseum art is not of East Asian origin, though they keep a small collection. We might wish to restrict the art we sample by the geographical location that our historical scenes take place in. This is possible with the Rijksmuseum API, but only approximately, by modern or historic country.

We’ve been playing with Unity3d, a game engine; we’ve made a picture frame asset that retrieves and displays a sample of historical art when the scene that it is placed in is played. A repository containing that asset can be found here. The script that retrieves art from the Rijksmuseum was written in Clojure, with the new Arcadia plugin; we hope to explore how the functional programming paradigm might help us further progress on the Muninn project.

We hope to retrieve art from the Rijksmuseum and place it in our statistically recreated scenes of historical events. The Unity3d asset that we have created facilitates this: we need to make more progress on statistically building the structure of our scenes, but we are now able to populate picture frames with art in our scenes once we have determined where they should be placed. It would be nice to display a description of the art to the viewer, to aid the analysis of the art in the context of the scene. Stay tuned for more information on this endeavour!

Language English

Tags:

Rijksmuseum

Historical Art

Information Retrieval