Sharing Data - Downloads Are The Key
Last week, Directions Magazine had a podcast about sharing data. The question was APIs or downloads. Now of course I’m partial to data downloads as I work for WeoGeo, but before I worked here, I was a big proponent of raw data. Personally, I believe it is one of the best ways for citizens to keep track of their government (local to federal). Not that I’m wearing a tin foil hat, but stats are built to lie and APIs tend to deliver what their “owners” want them to do. Raw data means everyone has an opportunity to check each other’s work. Of course, raw data can be manipulated as well, but it is harder to obscure.
Mike Daisey
Data in APIs can make a nice story, but they don’t always tell the truth
But APIs do serve a purpose, they allow developers to work with data that they might not understand. Let’s say for example that there is a great dataset of Superfund cleanup locations that is in Esri File Geodatabase format. Most of us reading this blog post know exactly what to do with that, either load it into our Esri tools, or use OGR to convert it to another format. But Joe Developer wouldn’t know that you need to use either and even if the instructions are there, GIS tools are very difficult to use. Thus even if you have raw downloads, they might not be useful at all for anyone.
One of the biggest reasons I joined WeoGeo was to work on how we could allow organizations (commercial or government) to share data in raw formats, but allow the users of the data to convert them into formats that are actually useful for their needs. Thus a user presented with an Esri FGDB could deliver that in a KML or CSV where they would then be able to use tools that they are familiar with to get the data ready for their use. Because this happens on the server side of WeoGeo, the end user doesn’t worry about what the native format is, just the format/formats they care about.
Content is King
Consuming Data
We’ve worked really hard with our partners to enable the power of enterprise strength ETL. We use our APIs to deliver raw data downloads, not formatted structured data that you must shoehorn into your workflows. This is important because it gives you the power to use the data as you see fit, not as how some developer of the APIs thinks you should. Clearly we at WeoGeo are focused on location data, but there are tons of other datasets that should also be available as bulk downloads by organizations.
Now I don’t want to make too much of a stink about APIs. They do serve a purpose and there is nothing wrong with having them if the data is available for download first. In fact it is probably a great idea to offer both, data downloads for those who want to work with the data and APIs for those who want to stick points on a map.
If you are looking at a great and simple way to deliver data downloads on multiple platforms, you can get started with WeoGeo and share your data right away.
Use TileMill to Create WeoGeo Tilepacks
I’ve professed my love of TileMill maybe once or twice before. One thing that I’ve always wanted was a way to create WeoGeo tilepacks in TileMill. Arc2Earth currently has rudimentary support for creating WeoGeo tiles, but it still requires some work. Dan Dye has put together a workflow to create a nice simple WeoGeo tilepack using TileMill and how you can upload it to your free library. Then once you’ve got that listing uploaded, you can easily share it using the new WeoGeo widgets like Dan did with the one below.
http://market.weogeo.com/datasets/tiger-tiger-conus-via-tilemill/widget.html?zoom=0&lat=4548183.2902543&lon=-10644845.198927
TIGER CONUS via TileMill
That’s a great, simple way to get sharing your data with other users. If you’ve been looking for a tutorial on how to use TileMill outside of the MBTiles format, take a look at Dan’s post. It is a great starting point.
Use TileMill to Create WeoGeo Tilepacks
I’ve professed my love of TileMill maybe once or twice before. One thing that I’ve always wanted was a way to create WeoGeo tilepacks in TileMill. Arc2Earth currently has rudimentary support for creating WeoGeo tiles, but it still requires some work. Dan Dye has put together a workflow to create a nice simple WeoGeo tilepack using TileMill and how you can upload it to your free library. Then once you’ve got that listing uploaded, you can easily share it using the new WeoGeo widgets like Dan did with the one below.
http://market.weogeo.com/datasets/tiger-tiger-conus-via-tilemill/widget.html?zoom=0&lat=4548183.2902543&lon=-10644845.198927
TIGER CONUS via TileMill
That’s a great, simple way to get sharing your data with other users. If you’ve been looking for a tutorial on how to use TileMill outside of the MBTiles format, take a look at Dan’s post. It is a great starting point.
Using Fiona with WeoGeoAPI
Over on the WeoGeo, Dan Dye has a new post about using Fiona with the WeoGeoAPI.
Since “JSON objects and Python dictionaries are semantically and syntactically similar”, working with JSON is a pleasure in Python and it is trivial to turn the geographic features returned from the WeoGeo API into GeoJSON. But sometimes you just want a Shapefile. You don’t have to be ashamed. I do too and I’m going to share with you the fastest, most intuitive, and most Pythonic method that exists to turn those geographic features into a Shapefile: enter Fiona.
Using one of the free datasets (TIGER) on WeoGeo Market, Dan was able to convert the JSON to a Shapefile that he could use with other projects. If you’ve been looking at a quick and easy way to get started with the awesome that is Fiona, check out Dan’s tutorial.
http://market.weogeo.com/datasets/tiger-tiger-conus-coverage/widget.html?zoom=0&lat=36.614452&lon=-95.6242725
TIGER CONUS Coverage
Dan’s Python Script
Just a couple lines of python code and you’ve got Shapefiles!
Using Fiona with WeoGeoAPI
Over on the WeoGeo, Dan Dye has a new post about using Fiona with the WeoGeoAPI.
Since “JSON objects and Python dictionaries are semantically and syntactically similar”, working with JSON is a pleasure in Python and it is trivial to turn the geographic features returned from the WeoGeo API into GeoJSON. But sometimes you just want a Shapefile. You don’t have to be ashamed. I do too and I’m going to share with you the fastest, most intuitive, and most Pythonic method that exists to turn those geographic features into a Shapefile: enter Fiona.
Using one of the free datasets (TIGER) on WeoGeo Market, Dan was able to convert the JSON to a Shapefile that he could use with other projects. If you’ve been looking at a quick and easy way to get started with the awesome that is Fiona, check out Dan’s tutorial.
http://market.weogeo.com/datasets/tiger-tiger-conus-coverage/widget.html?zoom=0&lat=36.614452&lon=-95.6242725
TIGER CONUS Coverage
Dan’s Python Script
Just a couple lines of python code and you’ve got Shapefiles!
New York Times - Bypassing Google Maps
Yesterday I was quoted in the New York Times:
“If you are a site just looking to put a pizzeria on a map, it’s no big deal, but if you are trying to put a brand around your mapping, it’s a big deal,” said James Fee, chief evangelist at WeoGeo, which provides location data. “Google says it will affect a very small number of users, but I have heard it will touch 30 or 40 percent of people who really depend on maps for their business. It could cost you tens of thousands of dollars a month.”
Now I assure you that I didn’t use the word “pizzeria”. I’m 110% sure that word isn’t used west of the Hudson. My point here is not just that people are going to have to pay for using Google Maps in the next year but enforcing how you can use the APIs themselves is going to be a problem. The fact that I’d have to use Google Maps tiles to display Google Geocoding results just kills that service for me. No matter how awesome Google’s geocoding is, I (WeoGeo) just can’t use their tiles.
You should read the Times article though. Quentin did a great job outlining the business case for using Google or going a different route.