OpenStreetMap aided important post hurricane mortality study Puerto Rico

A recent study published in the New England Journal of Medicine is making the news- Mortality in Puerto Rico after Hurricane Maria

The study puts the number at around 4,600 deaths which may be attributable to the hurricanes (Irma and Maria) which damaged Puerto Rico’s infrastructure. The storms left a significant portion of the island without electricity, potable water, and communications for an extended period of time. Access to supplies and movement was hampered by landslides, damaged roads and bridges.

While there is no dispute in the sharp uptick in overall deaths in Puerto Rico in the months immediately following the storms, linking the deaths to the storm has been a contentious issue. In the days and weeks following the storm hospitals were either functioning with reduced capacity or none at all. Government resources understandably were directed to recovery efforts, so counting the dead was not a top priority. The way that the government tallies the dead does not help either as storm related deaths are counted only if they are certified as directly caused the storm – dying after getting hit by flying debris during the storm counts. Yet, an elderly diabetic person who’s insulin spoiled because of a lack of refrigeration and died because his glucose got out of whack is considered to have died of complications from diabetes. A person with a respiratory infection may have gone without early treatment because of damaged roads and died as a result of complications – died of respiratory disease not because of the storm. No communications meant no 911. Such conditions, also takes a toll on mental health, so suicide rates also increased during this period.

171205-9296-1
Months after the hurricane, certain roads were still susceptible to landslides and communities lacked electricity, running water and communications.

OpenStreetMap data aided this study in ways not possible only a few years ago. On a recent radio interview, Domingo Marqués, one of the study’s authors, said that without the map density data this study would not have been possible¹. Thanks to a worldwide push lead by the Humanitarian OpenStreet Maps Team and other contributors holding map-a-thons and working individually – sufficient map data for Puerto Rico was largely available by the time the study needed it. For this study in particular, OSM information was used for selecting the sample.

From the study:
Sampling buildings using OpenStreetMap
Households within barrios were identified using OpenStreetMap (OSM) layers for structures identified as “buildings”. For each randomly selected barrio, we iteratively downloaded structure information using the OSM overpass API, calculated centroids for structures identified as buildings, and randomly sampled 35 locations. We generated geospatial PDFs for each barrio level with an OSM base layer, a barrio boundary and the sampled building points. The geospatial PDFs were loaded on Samsung Tab A 7” Android devices and displayed using PDFMaps. Enumerators were trained to load maps, identify their position and navigate using these geospatial PDFs.

The study thanked OSM contributors and serves as another example to OpenStreetMap’s usefulness.

171021-9034
Map-a-thon’s like this one held in San Juan, Puerto Rico helped improve OpenStreetMap data

As somber as this mortality study is, it can give us hope for better responding for catastrophes in the future by understanding how these deaths occurred. Traditional hurricane preparedness centered towards seeking shelter away from areas prone to flooding. Analysis of the causes of these fatalities along with OpenStreetMap may change this thinking. A location may not be prone to flooding, but may be still vulnerable because of landslide cutting off the only access road. Medicine, Potable Water and other supplies could be pre-positioned prior to the storm’s arrival and tailored on demographic figures to better serve communities which may have a hard time evacuating. After a storm, rapid post disaster data analysis can optimize relief resources to people in need. Temporary clinics could be set quickly up after a storm in critical locations to tend people suffering from chronic diseases or respiratory disease in order to avoid any complications which could lead to death.

OpenStreetMap and the continuing contribution its volunteers in drawing and identifying buildings and other physical features will hopefully play a role in many other studies and applications in understanding this disaster and preparing for future ones worldwide.

¹ 5/30/2018 AM 810 Fuego Cruzado interview
Advertisements

Finding where a photo was taken using Google Vision

Scanning photos taken by grandparents on a trip to Europe in 1960 is quite fascinating. Seeing the places they visited, some which I have also had the opportunity to visit as well, is a nice way to remember them. However, the photos presented a bit of a challenge as while some had written captions mentioning the location they were taken, most lacked this information.

Modern digital cameras embed metadata into an image file with details such as the date/time taken and geolocation. These bits of information make it easier to know where a photo was taken. So with these analog photos- I have only a black and white image of an unknown place.

1960’s photos meet Artificial Intelligence

Luckly, modern image recognition techniques can identify landmarks. Google’s Vision API can identify an image’s location by using AI smarts to compare them to a vast image dataset. As more images are fed, Google Vision “learns” more about landmarks and the objects contain within the images. While the API is targeted for application developers, Google provides a web site in which you can upload an image and it returns this information as well.

Google Vision API Website
The Google Vision API provides a way of identifying landmarks from photos. In this example, the service correctly identified the photo as taken at the Buen Retiro Park in Madrid, Spain – https://cloud.google.com/vision/

In mobile devices, Google Lens also uses this technology to recognize landmarks and present relevant information.

Google Lens
Google Lens uses Google Vision to identify landmarks from images.

 

Adding location information to the image file metadata

After positively identifying the landmark and geographical location where the photo was taken using Google Vision, I turn to GeoSetter for adding the missing geolocation information as well as captions to the image file metadata. Adding this information allows other applications and services to use it as well.

 

GeoSetter
Adding geolocation information to an image file using GeoSetter – http://www.geosetter.de/en/main-en/

 

OneDrive
Applications or services as OneDrive can use geolocation data to display the location on a map. The caption is also displayed showing the name of the monument as it was identified with the help of Google’s Landmark Recognition engine.
2018-05-22 (1).png
Geotagged photo shown in Windows Photo Gallery – the added metadata of the location taken is shown as a Geotag.

Related:

Moving away from Windows Photo Gallery Geotags

Windows Photo Gallery “Geotags” was a nice feature for adding location information to photos. It is no longer supported and has caused some angst among some users. So I am writing this post to provide a way to access and maintain the geo location information in your photos.

First, a quick explainer on how geotags are saved in image files and used to work in Windows Photo Gallery (WPG) – As you may know, photo files such as JPG can store additional information called metadata. The best analogy for understanding what metadata is by imagining a printed picture with written information written on the back. There are multiple ways (formats) of writing this information known as EXIF, IPTC, XMP. Think of it as paper forms with fields (such as date, time, caption, locations) to fill in, which are added to a photo.

WindowsPhotoGallery_Geotag
A photo taken at the Seattle Central Library shown in Windows Photo Gallery. Placing the mouse over the geotag would reveal all the geotag information.

The fields which Windows Photo Gallery uses for geotags are: IPTC Core and Extension Location Fields (Location, City, State/Providence, Country) and EXIF GPS Latitude, GPS Longitude.

Here is the general logic behind Windows Photo Gallery’s Geotags (in order):

1. If a photo already contains Location, City, State/Province and Country fields filled in, WPG would use the information it has to display as the Geotag. It would display the IPTC Extension fields as the first choice (if available) and the IPTC Core “legacy” fields (if available) as the second option.

2. If a photo has GPS Latitude and Longitude, but no City, State/Province, or Country information in the fields described in (1), then WPG would consult a Microsoft web service to determine the “Geotag” based on latitude and longitude, this process is called reverse geocoding. It will not however, write the “Geotag” information back to the file, unless they are edited manually by the user.

3. If you, the user, edit a Geotag in WPG manually, it will be saved back to the file and that information becomes the “geotag”. However, here it is where it gets a bit tricky- There are multiple Location, City, State/Province, Country fields among the different metadata standards (IPTC and within XMP). WPG uses the “IPTC Extension- Location Created” fields to store the “Geotags” info within the photo.

IMG_3394
Windows Photo Gallery “Geotag” rename dialog box. When edited, the information is saved back to the file to the IPTC Extension “Location Created” fields.

Here is an example of the metadata from one of my photos. You will note multiple fields which may seem to contain redundant information, but the ones WPG would write to are just four which start with “Location Created”. These fields are detailed in the 2008 IPTC Extension Spec, further discussion on how this information is handled by certain applications can be found on the Metadata Working Group Spec.

Location Created City Seattle
Location Created Country Name United States
Location Created Province State Washington
Location Created Sublocation Seattle Central Library

Given that Microsoft decided to discontinue WPG last year, the service which determines the geotags is no longer working, so holdout users may find these fields empty or have trouble adding new geotags. Hence, exiftool, Lightroom or other photo management applications will only be able to show you geotag information if it was written within the file.

GeoSetter to the Rescue

As a workaround, I rely on a freeware application called GeoSetter (which internally uses exiftool). Geosetter uses a service from Geonames.org, in a similar fashion which WPG did, to aid in finding location info as well it allows users to edit them manually. I exclusively have been using GeoSetter for some time, which unlike WPG it will always save the information back to the photo file. GeoSetter also allows one to edit the latitude and longitude info, which I was unable to do so in WPG.

GeoSetter_Edit_Location
GeoSetter’s Edit Data dialog allows users to edit EXIF GPS as well as IPTC Location fields.

However, as good as the Geosetter is, there is a slight catch – Geosetter by default does not read nor write to the newer 2008 IPTC Extension format which Windows Photo Gallery writes to. This is not just an issue with Geosetter, other photo management tools, like XnView MP, still primarily use the IPTC Core “legacy” Location fields, instead of the newer IPTC Extension Location fields. The IPTC Photo Metadata User Guide, explains the reasoning of creating the IPTC Extension fields. Luckily, Geosetter is versatile enough to provide a means for a workaround.

To make GeoSetter read any existing WPG Geotag – You will need to copy any saved “geotag” information from the IPTC Extension, to the equivalent IPTC Core fields using an exiftool command. In a previous post I described how to use exiftool for accessing Windows Photo Gallery. You will only need to run this step once on your photos from the command line. I advise you to make a backup copy of your files before executing it.

exiftool *.jpg -"Location<LocationCreatedSubLocation" -"City<LocationCreatedCity" -"Province-State<LocationCreatedProvinceState" -"Country<LocationCreatedCountryName" -r -overwrite_original
-r means that it will execute recursevly, so that all subfolder are included.
-overwrite_original means that exiftool will not create a backup of the file.

Again, this will only work on file which WPG saved the geotag information to the file, otherwise the fields will be empty.

To configure GeoSetter write back information to the newer format when an edit is made– In the GeoSetter application menu, go to File | Settings. In the Settings dialog, go to the “ExifTool” tab. Ensure that the “Use Additional Exiftool Commands after GeoSetter command” checkbox is enabled and add this text to the text field underneath:

-execute -"LocationCreatedSubLocation<Location" -"LocationCreatedCity<City" -"LocationCreatedProvinceState<Province-State" -"LocationCreatedCountryName<Country" -"LocationCreatedCountryCode<CountryCode"

 

GeoSetter_Exiftool_Settings
GeoSetter’s Settings dialog. Adding additional exifool commands allow custom actions such as copying field values to another. In this case location information is copied to IPTC 2008 Spec fields.

 

If you are still a die hard Windows Photo Gallery fan, you will find that with these tips the geotag information populated with what you was entered by GeoSetter. While the reverse geocoding capability may be gone, you can still use WPG sort by GeoTag and Search functionality as before. Still, looking forward, I would avoid editing geotags in WPG and rely instead on GeoSetter as a replacement for this functionality in order to avoid the problems previously described.


References:

Related Posts:

​Crowd-sourced maps assist in Hurricane Maria relief efforts: How volunteers are helping put Puerto Rico on the map

As Hurricane Maria‘s winds and rain battered our home in San Juan, among the many thoughts that bounced in my head in those long hours was wondering about the people living in the mountainous regions of the island. The winding roads, heavy foliage, cliffs, bridges and terrain susceptible to landslides could make it the worst place to be in such a storm. Many small communities on those mountains would become isolated for days.

The storm left us without power, water and cellphone service. In the following days, I managed to connect to one of the few hotspots available and got an email indicating that The Humanitarian Open Streets Maps team was responding to the disaster per the request of the Red Cross. As a local OpenStreetsMap user, I new what that meant. Yet never imagined how it would take shape and how vital that information would become to the relief efforts.

OpenStreetMaps, or OSM as the name implies, is an open and publicly available geographical database which anybody can use and edit. Think of it as the Wikipedia for maps. Governments, Non-governmental organizations and companies such as AppleFoursquare and Yahoo use OSM. You may have seen OSM data in a map on your phone without even knowing it.
For some time I have tinkered as a contributor to OSM in my spare time. A small local group of volunteers have been able in getting some local government municipalities to contribute data to OSM. Most of it may be out of date so OSM volunteers review and even sometimes perform field work to ensure accuracy and quality. Local organizations such as Foundation for Puerto Rico have sponsored mapping activities to under-served communities. Initiatives like these have led to good PR road information in OSM. While larger cities may have good building descriptions, rural areas especially the mountain regions in Puerto Rico may have very little geographical information available.

When a major disaster strikes and a large scale response effort needs to be executed knowing where those building structures are located is essential. That’s when the Humanitarian OSM team can quickly turn the focus of mapping volunteers to analyse satellite imagery on a location in need. To my surprise, universities stateside sprang into action organizing Map-A-Thons for Puerto Rico. In these map-a-thons events, experienced OSM users recruit newbies and teach them the basics to put them to work in outlining buildings and drawing roads over satellite imagery. I even encouraged my brother who lives in NYC to attend one of the events. An avalanche of data ensued and its importance cannot be underestimated. When someone’s home is outlined on a map, it means something. It means that it exists, it is there and that a someone may live there.

I visited the Red Cross Operations Center in San Juan and witnessed something truly amazing. A flurry of activity with volunteers from around the world gathering to help our island. I had chance to talk with a Red Cross worker working the maps data and the folks responsible for prioritizing the relief efforts. In such a situation, it only beckons a human being to ask “How can I help?”, which I did. I was told the Red Cross was printing large format maps elsewhere and they needed that capability there. I quickly contacted some friends which where able to get them a large format printer to the ops center. As best as I could contacted the local OSM volunteers and GIS professionals, which could aide the Red Cross.

Red Cross volunteers in San Juan, PR hold up a map of Puerto Rico
Red Cross volunteers in San Juan, PR hold up a map of Puerto Rico

The Red Cross is providing disaster relief right now, as well as employing highly capable geographical information systems (GIS) tools with volunteers on the field to catalog which roads are accessible or obstructed. That obstruction could be a landslide, fallen trees or a collapsed bridge. The information is shared with FEMA and local agencies which in instances in coordination with the military determine the course of action for rendering aid.

VIDEO: Rutgers ‘map-a-thon’ aids relief efforts in Puerto Rico

Disaster relief volunteers from various organizations are being sent to every corner of the island, including hospitals, shelters, and elderly homes. Volunteers coming from afar, not familiar with Puerto Rico may need map data to navigate a post hurricane disaster zone where street signage may have been blown by the fierce winds.

So one can imagine a repeating story playing out in Puerto Rico. That of an elderly person living in the mountainous region of the island, who may be alone, without power, enduring sweltering heat, with no clean water and in need. Yet thanks to a someone in another part of the world who drew a simple outline of his house, a relief worker knows that there is a home there, how to get there and a knock on the door can happen.


You can help Puerto Rico and the Virgin Islands in various ways. Participating in a Mapathon, or donating to the Red Cross are some.

If you have a computer, an internet connection and some time you can assist in mapping Puerto Rico.

 

Accessing Windows Photo Gallery Metadata using Exiftool

With the demise of support to Windows Photo Gallery, it may be a good time to plan an app migration. I have seen various posts and comments on this, particularly after all the time and effort you may have spent tagging photos. The app which is meant to replace Windows Photo Gallery is the Windows Photos App. Unfortunately, the Windows Photos app does not support Captions, Descriptive Tags, People Tags nor GeoTags and to date I have not found any information which points that those features will be supported in the future.

So do not fret, as one of the pluses of using Windows Photo Gallery is that most of this information is stored into the image file and is accessible in Windows Explorer as well as any other apps which support photo metadata standards. Only in some instances this data is not stored to the file itself, such as “Flags” or if the image file in PNG or is set to “read-only”.

Understanding where the metadata is stored

Windows Photo Gallery stores much of this information as photo metadata using standards such as EXIF, IPTC IIM, and XMP (IPTC Core, IPTC Extension, Dublin Core and Microsoft Schemas) . I will not delve into the specifics of these standards but it is worth knowing to which fields the information is mapped to. In some occasions some information may be stored in multiple fields. For example, WPG captions information is stored in the XMP:Title, XMP:Description as well in other IPTC and EXIF fields.

The following table lists some of the photo information displayed in Windows Photo Gallery and the corresponding metadata fields from where the information is read and written to. I created this table from plain observation, if you find any other behavior let me know.

For reading and writing to these tags I highly recommend the excellent Exiftool command line utility. It may be daunting for some users to use the Windows Command line so I will try to be as specific as possible.Reading Windows Photo Gallery Metadata using Exiftool

Installing Exiftool

  1. (For Windows Users) Download the stand-alone Windows Executable from the Exiftool site.
  2. Unzip the exiftool(-k).exe and rename it exiftool.exe
  3. Copy the exiftool.exe to your c:\windows folder or to a folder contained in the PATH variable so it is accesible in any directory/folder.Detailed installation information can be found here.

Using Exiftool

  1. Open your command prompt in a folder containing photos either by running the Command Prompt shortcut in the Windows App Menu or by right mouse clicking on a folder while pressing the key  and selecting “Open Command Window here”.
  2. Confirm you have the current exiftool version by typing into the command prompt:exiftool -ver
  3. Pressing will return the version number.

Just typing the exiftool and the image file name will bring a host of information.

Exporting Windows Photo Gallery information to a File

This example will produce a file named “PhotoMeta.txt” which will contain a table with the filepath, filename, date and time photo was taken, camera maker, camera model, wpg caption, wpg descriptive tags, and wpg people tags contained in the current directory and its subdirectories.

Example:

exiftool -T -Directory -Filename -DateTimeOriginal -Make -Model  -xmp-dc:Title -xmp-dc:Description -xmp-dc:Subject -RegionPersonDisplayName -r *.jpg > PhotoMeta.txt

Using the “-T” option will output tab-delimited results. The “-r” option is used to include all the subdirectories contained within the specified “Pictures” directory. You can later open this table in Excel or import it to a database such a Microsoft Access for quick analysis.

Using IPTC location identifiers to link your photos to knowledge bases

In 2014, IPTC released an update to its photo metadata standard which supports the adding of “location identifiers” to photos. In simplest terms, a url can be added to the photo metadata which links the photo to geolocation identifiers (in the form of a URI) provided by services like WikiData, Foursquare, Facebook, DBpedia, Geonames, among others- a form of linked data

Wikidata_LocationIDWhy is this interesting?

As more cameras are GPS enabled it aides in establishing the “where” the photo was taken. A common example, is when you take a photo with your smartphone and share it on Instagram. During the upload process, Instagram provides a way to add the location where the photo was taken. Instagram uses the GPS data of the photo and looks up locations from the Facebook Places database (Instagram switched from using Foursquare to Facebook Places after being acquired by Facebook). After your photo is uploaded Instagram the photo is “linked” to that location. You can quickly see the photos you and other took in that same location. This IPTC standard simply allows you to save that association within the file.

Now, the benefits from this may not become entirely clear now but if such a “location identifier” is already included within the photo it could bring with it some benefits. From the previous example, it could ease the upload process since Instagram or any other photo service may be able to deduce quickly the location of a photo. I am not sure of any photo services which does this yet, but for example, Flickr for some time has implemented something similar using machine tags

In Flickr if you add a tag to a photo pointing to a foursquare location in the form of foursquare:venue=, Flickr recognizes the location and adds a map with the foursquare location.

A Smarter Search

Say you attend a basketball game in Madison Square Garden, and take some photos. Your smartphone recognizes where you are and “tags” the photo with the WikiData entry for “Madison Square Garden” (Wikidata Q186125, Foursquare VenueID). You upload a photo to an online photo sharing service, such as Google Photos and perform a search for “basketball game” or the team which played on that date. Given that the Wikidata identifier is associated with the type of venue and the type of games played there, a search engine with some “smarts” can deduce that a basketball game was played on the date you took that photo. Similarly, if Google Photo employs some of its image recognition on the photo it can have some additional information to make a better analysis of the image.

Also, a location may have different names and may be spelled differently in several languages. Linking a location to a Knowledge Base such as Wikidata allows a search engine to better understand the context of a photo.

So you see, the IPTC Location identifiers opens up some interesting scenarios and it is quite useful for photo archivists, librarians or a home user which may also be looking for ways to link photo to similar knowledge bases.

Adding Location Identifiers with Exiftool

Using Exiftool it is easy to add Location Identifiers. Simply use the LocationCreatedLocationId or LocationShownLocationID tags as follows:

exiftool <filename> -"LocationCreatedLocationID+=https://foursquare.com/v/madison-square-garden/4ae6363ef964a520aba521e3"
*The += will add values to the Location Created List.