Tag Archives: ArcGIS API for Javascript

County Level Unemployment Maps

A new unemployment rate map has been making its way around the Internets lately. We here in the APL thought it would be a good time to post a link to a similar mapping app we put together earlier this year:  Unemployment Rates – March 2009 to September 2009. This app originally showed October 2008 – April 2009 rates but was recently updated with new data from the BLS. 


Our app basically shows the same data as the app linked above but includes a few extra goodies. There’s the ability zoom to a specific state or county by clicking a place name in the sidebar. Once zoomed in to a specific county, a chart for that county’s unemployment rate over time is displayed. Also, since this app was built with the ArcGIS API for JavaScript, all the usual navigation tools like shift + click and drag to zoom are available.


There are a few other examples of this type of app. The Bureau of Labor Statistics(BLS) hosts their own app to display this information:  BLS Unemployment Rate Mapping Application. My personal favorite to visualize this data is probably one done by the New York Times back in March. The filters for metro areas, rural areas and manufacturing centers are a nice touch.


Contributed by Derek Swingley.

Posted in Uncategorized | Tagged , , | 3 Comments

New Lens Dijit for the ArcGIS API for JavaScript

Yesterday I added a new dijit to the ArcGIS API for JavaScript Code Gallery: the Lens Dijit. It could also be called an X-Ray dijit. Here’s a screen shot:



Everything you need to get started using it is in the ReadMe.txt included in the download but, if you just want to take it for a spin, you can try it here:  lens dijit demo.


Please leave any feedback in the comments here or at the resource center.


Contributed by Derek Swingley.

Posted in Uncategorized | Tagged , , , , , | 3 Comments

Point Data, ArcGIS Server Base Maps and KISS

One of the most common requests for a web mapping application is to simply display points on a map. I won’t go on and on about the general concept as we’ve all probably seen countless examples of these maps. The basic idea is point data are represented by icons that are clickable. When you click a point, you get info about what’s happening there. It’s just simple points on a map.


A few months back, a couple of us in the lab were tasked with developing a simple workflow that we could publish as a quick and easy way for non-developers to display some of their data on ArcGIS Online (or any other ArcGIS Server) base maps. KISS was definitely the theme of this mini-project. We quickly came up with a solution, and eventually uploaded it to the ArcGIS API for JavaScript code gallery under the title “Mapping Point Data.” See the default, dead simple, points on a map app here.


There are two applications bundled in that sample but both serve the same purpose. For this post, I’ll only go into detail for the app that deals with data that already have x and y coordinates. The apps come with detailed “How To” documents that serve as a step-by-step walkthrough to get the app running with your data.


When working with data that already have associated x and y coordinates, the basic workflow is:



  • download and unzip the file from the code gallery page for this app

  • edit the app’s configuration file, appConfig.js, to reference your data and the necessary fields

  • copy the edited configuration file, your data file and the html file from the original .zip file to your web server

That’s it! Navigate to the html file on your server and you should see your data displayed on a base map. The default configuration will display your data on top of the ArcGIS Online (AGOL) street map but you can easily change this by editing the configuration file to point to a different AGOL map service or a map service of your own. Below is a screen shot displaying some of the sample data included with the code.



Of course, you can get into more complex scenarios. One that’s covered in the “How To” doc is using/displaying data from multiple files. And there might be some pre-processing required to make sure your data uses the correct coordinates. If you just need to do a simple conversion from WGS84 to Web Mercator (or vice versa), check out geographicToWebMercator() or webMercatorToGeographic().


If you run into any issues using these apps and/or have questions, please let us know in the comments.


Contributed by Derek Swingley.

Posted in Uncategorized | Tagged , , , | Leave a comment

No Download Required: View Data.gov Shapefiles Directly In Your Browser

We recently submitted the Shapefile Viewer application to the Apps for America 2: The DATA.gov Challenge contest, a project of the Sunlight Foundation. We believe DATA.gov is a great resource of publicly available government data. With the recent addition of the geodata.gov references to the DATA.gov site, we now have over 100,000 geospatial datasets and services available for searching, browsing and/or download.


In the ‘Raw Data Catalog’ and ‘Geodata Catalog’ sections there are many zipped data files available for direct download, including many Shapefile datasets. Typically, if you want to use these Shapefile datasets, you first need to download the zip file, unzip the contents to your local machine, and then finally view the Shapefile dataset with your favorite GIS. Unfortunately, there are times when the metadata associated with each entry does not provide enough information for you to decide if a particular Shapefile dataset is the one you’re really looking for. We also realize that not all DATA.gov users have a GIS application that supports the Shapefile format, but they’re still interested in the data.


Ideally you’d want to look at the Shapefile dataset before you decide to download it to your local machine. This is where the Shapefile Viewer application comes in: it allows you to visualize and query these Shapefile datasets directly in your web browser, allowing you to decide if a particular Shapefile dataset is the one you’re looking for.


The Shapefile Viewer web application relies on a Geoprocessing Service to do the hard work. The web application simply sends the URL of the user selected zip file as an input parameter to the Geoprocessing Service. The Geoprocessing Service is responsible for downloading the zip file remotely, unzipping the contents, fixing the Shapefile datasets, creating a map document, creating and rendering layers, and publishing a map service. Once the map service is created on the server, the Geoprocessing Service sends back the URL of the new map service to the web application. In the final step in the process, the web application adds the new map service to the map and allows the user to query the Shapefile dataset by identifying features on the map.


Contributed by John G.

Posted in Uncategorized | Tagged , , , , , , , , | Leave a comment

Custom Objects in dojo.ItemFileReadStore: Using a Type Map

The GeoChalkboard Blog recently published a post about using the dojo.ItemFileReadStore (IFRS). That post does a good job of introducing and discussing basic usage of the ItemFileReadStore, but it leaves out one important aspect, the Type Map.


Natively, an IFRS allows you to store primitive JavaScript types such as strings and numbers. If you want to store custom objects within an IFRS, geometry for instance, then you need to tell dojo a little about the objects and provide some extra info in your JSON file.


You tell dojo about your custom objects through a Type Map. The documentation about Type Map is comprehensive and does a good job of explaining the various options. I recommend sticking with the simplified form. The Type Map itself is a property of an object that is passed into the IFSR constructor. In its simplest form, the value for Type Map is an object that contains custom type names as properties and constructor functions as values. Simple, right? The following example should clear up any confusion.


Here’s some code I used in a dijit I built to zoom to a specific state and/or county:

this.stateStore = new dojo.data.ItemFileReadStore({
url: dojo.moduleUrl(“apl.dijit.ZoomTo”, “data/states_wgs84.json”),
typeMap: { “Extent”: esri.geometry.Extent }
});

The code above is setting up an ItemFileReadStore from which you can retrieve extents. It would be nice if all you had to do was specify the Type Map, but, unfortunately, it’s not that simple. To successfully use custom types in an IFRS, you also need to specify the object type within your JSON. Each custom object needs two specific properties: _type and _value. _type has to match a property name in the Type Map object and _value is passed to the custom type constructor function. Here’s an excerpt from states_wgs84.json file:

{
“identifier”:“name”,
“label”:“name”,
“items”:[{
“name”:“Alabama”,
“abbr”:“AL”,
“fips”:“01″,
“extent”:{
“_type”:“Extent”,
“_value”:{
“xmin”:-88.4729522509999,
“ymin”:30.2336047200001,
“xmax”:-84.8940162469999,
“ymax”:35.0160337240001,
“spatialReference”:{“wkid”:4326}
}
}
}
}

Notice that the value for _type from the JSON file matches a property of the typeMap used in the IFRS constructor. Once you have custom types defined in a Type Map, and set the proper values for _type and _value, you can retrieve and use custom types like any other type coming from an ItemFileReadStore. The code below retrieves a single extent from the store using fetchByIdentity:

this.stateStore.fetchItemByIdentity({
identity: placeName, onItem: this.handleExtent, onError: this.oops
});

To see a complete working example of creating and using custom types in an ItemFileReadStore, see the ZoomTo.js file that is a part of the Zoom To State/County Dijit.


 


Contributed by Derek Swingley.


 

Posted in Uncategorized | Tagged , , , | Leave a comment