The Los Angeles GeoHub represents, in many ways, the next generation GIS data portal. It is in my view what a data portal should be, and given the population and areal size of Los Angeles, that the portal is robust makes it even more impressive. The data user can search the city’s open data site, and also do something that not all sites allow: “Explore all data”. At the time of this writing, “exploring all data” resulted in 554 results, which one can then add to “my favorites” for later investigation and download. One can also explore the data by category, including business, boundaries, health, infrastructure, planning, recreation and parks, safety, schools, and transportation. Most data sets can be downloaded as a spreadsheet, as a KML file, or a shapefile. These layers include grasslands, fire stations, cell phone towers, road work projects, traffic, parcels, and dozens and dozens more–even bus stop benches and other treasures. Each download is quick and painless.
A unique and very useful characteristic of the GeoHub is that each layer lists the number of attributes, which are easily displayed on the site. Another wonderful feature is that each layer is displayed above its metadata listing as a web service inside ArcGIS Online, which can be opened immediately in ArcMap or ArcGIS Pro or streamed as a GeoJSON or GeoService as a full or filtered data set. Applications based on the data can also be accessed on the site, such as the CleanStat clean streets index and the social determinants of health app. And yet there is even more–charts can be generated straight from the data, and a whole set of ArcGIS Online mapping applications that the city has generated are displayed in a gallery here. Because of these applications, the site can be used effectively even by someone who is not familiar with how to run a GIS to understand Los Angeles better and to make smarter decisions.
If you are a data user, explore the data on the GeoHub today. If you are a data administrator, consider using the GeoHub as a model for what you might develop and serve for your own data users in your own location.
A recent article on BusinessInsider reported the re-launch of Google’s location sharing feature as an update to Google Maps. Originally available as Google Latitude, the first version prompted a report highlighting the risks of inadvertently sharing personal location information. Although the location sharing options seem similar second time around, the focus seems to be on the benefits of sharing this type of information and as the article notes, although the privacy concerns haven’t away, they are a footnote rather than the headline.
What has changed in the intervening years appears to be the perceptions about sharing personal location information. Is this because consumers of such services heeded the warnings and shared with discretion so fears were unfounded, or because the risks were not as great as originally thought? Other location sharing applications, such as Glympse and Swarm, stayed the course and developed their niche products away from the spotlight that tends to focus on Google. Have these services paved the way for Google to try again? Whatever the reason, Google is confident enough of a favourable reception to re-release their location sharing technology as part of their flagship application.
A group of people at the Civic Analytics Network recently wrote “An Open Letter to the Open Data Community” that focuses on topics central to this blog and to our book. The Civics Analytics Network, is “a consortium of Chief Data Officers and analytics principals in large cities and counties throughout the United States.” They state that their purpose is to “work together to advance how local governments use data to be more efficient, innovative, and in particular, transparent.”
The letter contained 8 guidelines the group believed that if followed, would “advance the capabilities of government data portals across the board and help deliver upon the promise of a transparent government.” The guidelines included the following:
- Improve accessibility and usability to engage a wider audience.
- Move away from a single dataset centric view.
- Treat geospatial data as a first class data type.
- Improve management and usability of metadata.
- Decrease the cost and work required to publish data.
- Introduce revision history.
- Improve management of large datasets.
- Set clear transparent pricing based on memory, not number of datasets.
It is difficult to imagine a letter that is more germane to what we have been advocating on the Spatial Reserves blog. We have been open about our praise of data portals that are user friendly–and critical of those that miss the mark–over the past five years. We have noted the impact that the open data movement has had on the data portals themselves–becoming in many cases more user friendly and encouraging adoption of GIS beyond its traditional departmental boundaries. The principles we have adhered to are also mentioned in this letter, such as being intuitive, data-driven, and with metrics. The letter highlights a continued need, the ability to tie together and compare related data sets, which is at times challenging given “data silos.”
One of my favorite points in the letter is the authors’ admonition to “treat geospatial data as a first class data type.” The authors claim that geospatial data is an underdeveloped and undervalued asset; and it “needs to be an integral part of any open data program”, citing examples from Chicago’s OpenGrid and Los Angeles’ GeoHub as forward-thinking models.
On the topic of metadata, the authors call for portals and managers to allow “custom metadata schemes, API methods to define and update the schema and content, and user interfaces that surface and support end-user use of the metadata.” Hear, hear! Equally welcome is the authors’ call to decrease the cost and work required to publish data. Through their point #6 about revision history, they advocate that these data sets need to be curated and updated but also allow historical versions to be accessed.
What are your reactions to this letter? What do we need to do as the geospatial community to realize these aims?