GeoScript in Action: Part 3

Soumya SenguptaIn first part of this series we explored GeoScript basics, sliced and diced some solar intensity data, and created several visualizations.  In the second part, we scripted a Web Processing Service (WPS) using the Python implementation of GeoScript. This script suggests the sunniest possible drive inside your current state based on your location and the number of stops you want to make. In this post, we will put together a simple web application that allows you to interact with the WPS service.

Goals of the Web Application

Using the web application, a user should be able to specify a starting point (either by clicking on a map or by using the browser’s geolocation capabilities) and the maximum number of sunny spots the user wants to make on the journey. The web application should then interact with the WPS to determine sunny spots based on the inputs provided. Finally, as an added feature, the web application will determine a route for the journey that starts from the origin and stops at the sunny spots.

User Interface

The web application user interface (UI) is designed to be pretty simple. The following figure shows the major components:


The steps the user has to follow are provided on the right-hand side. The results are shown in the different sections below that and on the map. The map itself has typical controls like a pan-zoom bar, a pan button, a drag box based zoom, mouse position based coordinate notifier and layer attributions.

Application Design

The web application is built using HTML5, JavaScript, and CSS. Major aspects of the application, like the interaction with the map and the WPS client, are implemented using OpenLayers 2 (version 2.13.1). The routing is implemented using the MapQuest Open Directions Service. The UI was stitched together using jQuery, Font Awesome, and elements from the Map Icons Collection. The base map used in this application is provided by OpenStreetMap.


The code of the web application can be found here and consists of an index.html page, a JavaScript file (js/gsblog3.js), and a CSS file (css/gsblog3.css). As expected, the single web page defines the UI elements while the CSS file makes them look good and the JavaScript file controls all the interactions.

The critical part of the JavaScript code is the interaction with the WPS server. The following code snippet, specifically those surrounding the OpenLayers.WPSClient class, shows how it is done:

// The 2 inputs to the WPS process.
var origin = new OpenLayers.Geometry.Point(startingPoint.lon,;
var waypoints = $('#stops').val();

// The WPS server needs to be specified. CORS restrictions apply.
// Bypassed by using ProxyPass directives on local Apache HTTPD.
var wpsClient = new OpenLayers.WPSClient({
    servers: {
         wpsserver: 'http://localhost/geoserver/wps'

// Details of the WPS interaction.
    server: "wpsserver",
    process: "py:solar_wps",
    inputs: {
        origin: origin,
        waypoints: waypoints
    success: function(outputs) {
            type: 'wpsClientExecuted',
            output: outputs

Using WPS

As you might recall, the WPS process that we created in previous post requires two inputs: the origin (what we call the starting point in the UI) and the number of waypoints (the number of sunny stops in the UI). After collecting those, the code proceeds to define the WPS client to the WPS server. In this case, the WPS server is hosted locally by a Geoserver instance with the WPS plugin. The WPS client then executes the request against the WPS process and handles the response.

If the web applications is viewed in Google Chrome with Developer Tools activated, the WPS request and the response can be seen. The following figures show a sample request-response combination.

Sample Requestrequest.png

Sample Response (truncated)


Another thing to note is the fact the points returned by the WPS may contain duplicates. So, if the user asks for five waypoints, the WPS will return five points but there might be only two unique points. To make the output more meaningful, the JavaScript code provided only works with unique points.

External Services

As is typical in many modern web applications, delivering different functionalities within the application requires the ability to communicate with external services. In this case, the application (running off an Apache HTTPD server) needs to communicate with the WPS server and (later on) the MapQuest routing service. In such situations, the web application is generally subject to strict Cross Origin Resource Sharing (CORS) policies. There are various ways to address the restrictions but In this case we chose to configure our local Apache HTTPD with a few ProxyPass/ProxyPassReverse directives.

Web Application in Action

Here a few screenshots showing the site in action.

After selection of starting point by clicking on the map:


After running the WPS and the route by clicking the Create Journey button:


Our Professional Services team works side-by-side with your team to help you make the most of your technology investment. Contact us to learn more!


GeoNYC April: Getting a grasp, from statistical analysis to real-time monitoring

Last month, GeoNYC brought together a trio of mapping projects that focused on analysis and real-time monitoring as Raz Schwartz, Jane Stewart Adam and Ekene Ijeoma presented their projects to the GeoNYC community at our April event held at Cornell’s NYU Tech Campus.

If you could’t make it to the event and want to check out what you’ve missed visit the treasure trove of past presentations. Use the hashtag #geonyc on Twitter or follow the conversations at Storify for a more complete picture of the event.

Don’t forget to attend GeoNYC tonight as Mauricio Giraldo (@mgiraldo), Kevin Webb (@kvnweb), Sharai Lewis-Gruss (@LoveRaiRai), and Dr. Raj Singh (@opengeospatial) discuss the changing world of open source geospatial software.

Raz Schwartz

Raz (@razsc), a post-doctoral researcher at Cornell Tech and a Magic Tech fellow presented CityBeat. It’s a real-time event detection and city-wide statistics application that sources, monitors, and analyzes hyper-local information from multiple social media platforms. What can you use it for?

CityBeat uses the massive amount of live geotagged information that is available from various social media platforms. It can be used to better understand the pulse of the city using the streams of geo-tagged information coming from Instagram, Twitter and Foursquare real time data.


Jane Adam Stewart

Jane (@thejunglejane), a grad student at NYU CUSP and apparently the only geostatiscian f0r miles

…presented KrigPy, a spatial interpolation library for Python that was refactored from the R gstat package. KrigPy has the major functionalities of the gstat package: variogram modeling; simple, ordinary, and universal point or block Kriging, sequential Gaussian or indicator (co)simulation; variogram and variogram map plotting utility functions. The project will be available on github soon.


Ekene Ijeoma

Ekene (@ekeneijeoma) talked about The Refugee Project, a collaboration with Hyperakt, which reveals the ebb and flow of global refugee migration over the last four decades based on data from the UN and UNHCR. It expands and reflects on the data, telling  stories about socio-political events which evolved into mass migrations.  It was agreed upon that it was quite beautiful:



A big thanks to Raz Schwartz at Cornell Tech for providing the space. And a special thanks to GeoNYC sponsors — Boundless, CartoDB and Esri — for supporting the event.

Thoughts from the Women in GIS Meetup

Alyssa WrightEarlier this month, Boundless sponsored a panel discussion at our new DC office on the role of women in the GIS industry and the challenges they face. We framed the discussion with the purposely provocative question: “Is your map sexist?”

Our panelists came from a variety of backgrounds: Nadine Alameh, of the Open Geospatial Consortium, Bonnie Bogle of Mapbox, Kate Chapman from Humanitarian OpenStreetMap Team, Liz Lyon from the US Army Corp of Engineers. Eddie Pickle, CEO of Boundless, opened the discussion with a recap of his experiences during his thirty-year career in geospatial.

Women in GeoSpatial MeetUp from Boundless on Vimeo.

Broad Agreement

There was a general consensus among the panel that women are in the minority when it comes to digital mapmaking and that the geospatial industry presents the same hardships for women joining the workforce — a general lack of introduction and mentorship for women, maternity and child care issues, company culture clashes, and some issues starting as early as college.

The panel also agreed that the field suffers due to a lack of inclusion and advocated for an industry that is served by multiple perspectives. Several panelists noted that being in a minority is not only challenging but also impedes the outputs and potential progress of the industry, as it is both hard for women to work and it’s stifling to innovation and the quality of work we want to produce as an industry.

From there, the discussion moved on to ways we can overcome these challenges.

Individual Observations

Nadine felt that you don’t see a conscious effort to support other women. She advocated on focusing on the next generation of mapmakers. We have to accept them and guide their professional growth into the industry. What and how we can provide to the the next generation? Mentorship and education were noted as some ways to create change.  Larger dialogues about the general structure of working in the industry would be useful for all, namely: how we treat each other, how we promote, what constitutes constructive ideas and dialogue, and who and how does one get invited to go to conferences. For women who find themselves working in unaccepting companies, how does a woman advance?  How are women and their issues integrated into the culture?

Kate recommended that we frame these issues within the larger open source context. Other open source companies have taken steps to see women succeed and we should all look at the models used in those communities. Kate recommended “Free as in Sexist: Free culture and the gender gap”.

Liz recognized the role bias and perspective play in mapmaking.  She thinks it was important for women to write more and document their voice and experience in the space. In general, women need to improve the visibility of themselves and women in general within the geospatial industry.

I think that because geospatial was always about place, the geospatial industry is well-positioned to lead the conversation about creating equity and gender balance in our digital world.  The quality of this conversation and the openness of the audience really made me optimistic about women entering both geospatial and open source communities.  There has been a lot of movement of welcoming diverse community and  I hope that this is an ongoing event to which more people can contribute.

Keep the conversation going!

Do you want to contribute and keep the conversation going?  Join us at #geoladies on Twitter!

The new home of Boundless

Anthony Denaro

Boundless is officially on the map at 38º 53′ 46.8632″, -77º 4′ 22.6549. After a year of co-working, co-locating and telecommuting, Boundless has moved into a new permanent headquarters in the Rosslyn area of Arlington, Virginia. It is just blocks from Metro, has a bike room, commuter showers, a big kitchen and, yes, it even has a ping pong table. Most importantly, it’s ours.

boundless 4

Our endgame was to find an office in a neighborhood that was close to to transit, bikeable, and with walkable amenities, and to design the office to encourage collaboration among our teams, keep them happy, and play host to the larger open source community.

Boundless (dragged) 2

We began our search along the Rosslyn-Ballston Corridor of Arlington County and Alexandria in Northern Virginia with our real estate broker, Greg Miele of Broad Street Realty. After months of hunting, our broker found this space, which was perfect on almost all counts. The office was designed in-house with collaboration from the DC office staff. OTJ Architects was the architect of record and Monday Properties Construction built out the space.

Boundless (dragged) 7

Our executive team wanted the office to be a collaborative effort and address the needs and desires of everyone working there.  The process of designing the space began by asking people what they wanted to have in our office. I created an idea board collected several dozen articles and photos from staff.

Boundless 1

We have a variety of Boundless staff located in the DC area: our executive team and project management team are here alongside members of our design, engineering, and sales teams. They all have different needs that needed to be addressed: Our executive team needs privacy but to be available. Our sales teams needs acoustical privacy and areas to meet with clients. Our design team needs space to brainstorm and collaborate on ideas for our new products. Our project managers need comfortable spaces to make phone calls and hold meetings with the engineering teams. Our software engineers need a place to focus but be available to each other. All need private space to make phone calls or to just work alone. And everyone wants whiteboards!


We included a variety of spaces to work: common meeting spaces, lounge chairs, big tables, phone rooms clustered desks, multi-person offices, a lounge area and an area to demo software to clients, with comfortable seats and a projector. A variety of modular furniture was purchased or built: staff had a choice between shared desks, standing desks or regular solo desks. I kept the purchasing open so staff could specify the type of furniture they wanted to work at. The result is a comfortable, functional office for our developers, designers and management to collaborate and work together in while they’re developing and improving the Boundless software stack.

Boundless (dragged) 3

The color scheme is bright. I found some knock-out wallpaper from Flavor Paper. The floors were sealed with shiny varnish to increase the reflection of natural light. We used energy efficient day-light spectrum lighting fixtures. I choose soft-colored woods and glossy laminates to enhance the feeling of openness and brightness. All the whiteboards (over 400 sq ft of whiteboards abound) also keep the light bouncing and lively. Hint: here’s a great way to make large whiteboards on the cheap.

Boundless (dragged) 8

Exposure to natural light was the most requested amenity but the space has just about twenty linear feet of floor-to-ceiling glass along about a hundred feet of exterior wall. I maximized the amount of light entering the space by removing a private office that took up about ten of those linear feet and kept the majority of the space open. The other two offices with windows were opened up with large interior facing windows. A series of smaller offices along an interior wall are divided by glass partitions. All of the offices have a visual connection with each other, allowing not only natural light to flow through but also encouraging visual contact among staff.

Boundless (dragged) 9

The space also has a large event facility that will host to meetups and events, like the recent Women in Geospatial event.

QGIS US User Group: Now on video!

For those who couldn’t attend the inaugural QGIS U.S. User Group last week, we managed to capture a lot of the event on video. Visit our album or check out the videos below!

QGIS US Introduction from Boundless on Vimeo.

Gretchen Peterson, Boundless from Boundless on Vimeo.

Gary Sherman, QGIS Project Founder from Boundless on Vimeo.

Kate Chapman, Humanitarian OpenStreetMap Team from Boundless on Vimeo.

Vivien Deparday and Yewondwossen Assefa, World Bank GFDRR from Boundless on Vimeo.

Tim Sutton, QGIS Project Steering Committee from Boundless on Vimeo.

QGIS US User Group: The beginning of something big

David Dubovsky

Last week, Boundless and others hosted the first ever QGIS U.S. User Group meeting with 75 attendees at OpenGovHub in Washington DC.

The event attracted a diverse group of experts and novices from organizations as varied as NOAA, the World Bank, USAID, the American Red Cross, Deloitte, LockHeed Martin, the CDC and many others. As a new member of QGIS community myself, I was floored by the energy of the group and how quickly the project is evolving.


Building QGIS

The day started with Jeff Johnson and Larry Shaffer setting the stage with presentations highlighting the history and evolution of QGIS from a shapefile viewer to full-fledged desktop application. Jeff went into detail about specific applications of QGIS, highlighting examples from NOAA and NASA. Larry picked it up from there and discussed the QGIS ecosystem and open source development community. He noted that plug-in development has been a long-time focus within the community and sees core development picking up steam in the coming year.


Next, Tim Sutton from the QGIS project steering committee joined remotely. Thanks to OpenGovHub’s fantastic conference abilities, Tim being in South Africa didn’t pose a challenge. Tim provided further context to Larry’s discussion on core and plugin development and the steering committee’s focus for 2014.


Later on, Gary Sherman joined remotely from Alaska and provided a brief history of QGIS development, including it’s origin as a shapefile viewer. Gary is also the author of the PyQGIS Programmer’s Guide on developing QGIS Plugins.

QGIS for Humanitarianism

After the remote sessions, Kate Chapman of the Humanitarian OpenStreet Map Team gave us an overview of InaSAFE, a QGIS plugin for emergency preparedness and response.


Vivien Depardy and Yewondwossen Assefa of GFDDR then presented on the role QGIS (and GeoNode) plays in their emergency response and disaster recovery efforts. Larry provided context to their efforts, applauding their development model calling it a leading example of development.




After a quick lunch we split into two groups for hands-on workshops. Jeff Johnson led “Using QGIS with OpenGeo Suite” and Larry Shaffer led “How to Become a QGIS Developer”. I attended Jeff’s session, which provided a good opportunity to review the fantastic QGIS documentation with an experienced instructor. Jeff used the documentation as a starting point but added his tips and tricks along the way. He ended by showing us how to use the OpenGeo Explorer plugin to publish data to GeoServer.


My colleague, Eva Shon, attended Larry’s workshop. Larry’s goal was to get more developers involved on the QGIS project. As the only core developer in the United States, he’s especially interested in increasing the number of developers from North America. He shared an early draft of QGIS core developer documentation and virtual machine images he’s working on intended to help new developers get started more quickly.


Next Steps

Whether you were looking for an introduction to QGIS or were already active in the community, the day had something for everyone. The event ended with a happy hour and the only question left was when we’d do it again. To learn more about QGIS, download and install it using the OpenGeo Suite installer and check out documentation to see what it can do. Stay tuned for next QGIS U.S. User Group meetings being planned in Atlanta and Seattle.


Thoughts from State of the Map US 2014

Gretchen PetersonThe State of the Map US 2014 conference, a two-day conference covering all things OpenStreetMap, was held this past weekend in Washington DC. It was nice to attend as part of the Boundless contingent and meet — in person — tons of people whom I had only heretofore known via the internets.

Aside from the inspiration provided by the gorgeous weather and the cherry blossoms, there was also inspiration in abundance at the conference for cartographers. Every cartographer should become familiar with OpenStreetMap data if they aren’t already. It’s a bit of a bear to work with because it is in a different structure than we are normally used to (nodes and ways mean anything to you?) but you’ll see the benefits if you download a state-wide or city-wide extract from one of several sites (such as geofabrik or Metro Extracts) and start using it in your map-making medium of choice. The dataset provides a comprehensive collection of roads, buildings and building types, points of interest, and so on. And it’s free!

There were many talks I didn’t get to see because there were two concurrent tracks, but the ones that I attended focused heavily on tools that for using OpenStreetMap data, including GeoGit, TileMill, Esri, QGIS, and PostGIS. However, there were still some cartographic takeaways.

  • Kate Watkins, Seth Fitzsimmons and Alan McConchie told us that a great way to build a stylistically cohesive basemap is to focus on three main hues, along with variations on those hues.

  • In that same talk we saw some great examples of labels that break all the rules: the leading and kerning (that’s line spacing and character spacing, basically) are decreased to negative values and the halos are very large and black. Of course this is the opposite of what most texts will recommend but it just proves that breaking the rules once in a while can make for some neat cartographic effects.

  • Eric Theise showed us that applying some of the devices of experimental film to maps, such as perception distortion, can be a creative way to get people thinking. Eric and I were discussing this later on in the day when he mentioned that he thought it would be interesting to have a map that taunted you if you tried to click on a feature to find out more about it. Something like, “You’d like to know what this building is, wouldn’t you?!”

  • Kevin Bullock told a great story about a map of India that was produced in the 1800s with crude tools, took 70 years to complete, and astonishingly accurate despite these and other limitations. And you thought your map products took a long time to produce!

  • Our own Jeff Johnson rounded out the weekend with a more technical talk that examined the ways in which GeoGit could lead to a more distributed and decentralized architecture for OSM.

There was a lot more material covered, of course, and these points focused just on the cartography aspect of OpenStreetMap use. All the talks are now posted on the schedule part of the conference website so definitely take the time to watch them!

If you’re still curious about State of the Map, I recommend this great recap from Peter Batty which provides more details about the event and reviews other issues in the OpenStreetMap community including vector tiles, licensing, passive crowdsourcing, geocoding and more.

Support story: Deterministic rendering order in SLDs

MassGIS As with our first support story, this one comes from MassGIS, the official state agency assigned to the collection, storage, and dissemination of geographic data. When a layer has overlapping lines or polygons, we often want to control which ones are rendered on top and which ones are rendered below. The classic example is when we have a roads layer that contains overpasses that we want to appear above regular roads at ground level. MassGIS was dealing with a land-usage layer which required one type of polygon to be rendered with a solid color and other types to be rendered above with specific patterns.

The Aral Sea Example

We can simulate this problem by taking a layer that has both current and historical extents of bodies of water. In particular we’ll look at the Aral Sea, which shrunk considerably in the twentieth century. We’ll want to style the historical extents using hatching and then overlay the current lake in a plain blue style. What we don’t want is to have the historical bounds drawn over the modern lake.

You can test on your own GeoServer install with the data and SLDs in this ZIP.

SLD Rules

Our first attempt at creating an SLD to draw the two polygons in the correct order is to use two rule statements: the first will match our historical layer (where attribute type is equal to historical) and the second will match the modern layer (where the attribute type is equal to modern). We expect this to draw the historical lakes first and then the modern lakes on top:

<sld:StyledLayerDescriptor version="1.0.0" xmlns:sld="">
    <UserStyle xmlns="">
          <Name>Historical area</Name>
          <Name>Modern area</Name>

Unfortunately, this gives us the opposite effect: the historical area has been rendered above the modern area.

Since this ordering of the rules didn’t work, we can try switching them around in the SLD, putting the rule for modern lakes first and historical lakes second. If you test this in GeoServer, however, you will see that the image that we get back is not affected.

Since reordering rules in an SLD does not affect the output image, we had to provide another approach.

SLD FeatureTypeStyle

The answer to the problem is to use the rules in separate <FeatureTypeStyle> sections of our SLD document:

<sld:StyledLayerDescriptor version="1.0.0" xmlns:sld="">
    <UserStyle xmlns="">
          <Name>Historical area</Name>
          <Name>Modern area</Name>

Why does this work?

Our first approach did not work since rules inside a single FeatureTypeStyle are applied to features as they arrive from the data source. GeoServer was drawing the modern Aral Sea first and the historical Aral Sea second simply because that is the order in which they were stored in the shapefile.

Even if the order had been correct, it would have been dangerous to rely on it for styling since that order could change at any time.

To reliably control the rendering order, therefore, we need the multiple FeatureTypeStyle blocks. GeoServer will draw each of these independently and then merge them in the defined order as the last step.

Benjamin Trigona-Harany leads our global support team from our offices in Victoria, BC. Interested in support or training for your enterprise? Contact us to learn more.

Use QGIS for the Bay Area Bike Share Open Data Challenge

Gretchen PetersonThe San Francisco Bay Area Bike Share Open Data Challenge is now underway, with entries due April 25, 2014. The idea is to use their open data on bike stations, bicycle traffic patterns, and weather to create an interesting visualization, map, or other product that adds value to the program.

Using open source mapping tools is a great way to explore the data and create winning entries for the contest. For those who are new to making maps out of open data, we’re here to help you get started. In this tutorial we’ll show you how to use QGIS, a popular mapping software product, to create a simple map out of the data. Build on this foundation to create your own contest entries and learn about data and geospatial technology along the way.

To get started, download all four data files from the contest website here. After you unzip the data you’ll see that it’s in CSV format. This is a comma delimited text file format that’s useful for spreadsheets and geospatial tables.

Installing QGIS

First, download and install QGIS. Then install the OpenLayers plugin, which simplifies adding some of the most common base layers, such as Google Maps or OSM, and makes it easier to visualize the bike station locations. You can install it by opening the Plugin Manager, selecting the Get more section and then searching for OpenLayers.


Now in the Plugins menu you should have a new entry where you can select the layers to add.



Adding bike share data

Add whichever basemap you like. In the following screenshots, you will see that we’ve added the Bing Road layer, which is less saturated than some of the others. A less saturated basemap helps to highlight the data that will be overlaid. You can zoom into San Francisco now or wait until the bike share data is added. To create the bike share data overlay, use the Add Delimited Text Layer button.


Add the station data file using the browse button. Use the x and y drop down selectors under Geometry definition to tell QGIS which fields have the latitude coordinates and which have the longitude coordinates. Latitude is y and longitude is x.


Your input should look like the screenshot above. Press OK. In the Coordinate Reference System Selector, type in “4326” in the Filter box and select WGS 84 in the box directly beneath it. Many — but not all — datasets in open data formats are in the WGS 84, or EPSG 4326, coordinate system.


The QGIS map should now look similar to the screenshot below. If it isn’t zoomed in properly, you can right-click the station_data layer in the Layers list and choose Zoom to Layer Extent.


Joining and analyzing bike share data

There is a lot of data in the other three tables to explore but they need to be joined to the station data first since the station data contains the geometry for displaying the data on the map, while the other tables are related to the station data geometry via its station_id field. Fields that can be used for joining are often described in files that come with the data. The README.txt file that came with this data follows this convention.

In this tutorial we’ll use the trip_data table to perform an analysis and display the results on the map. First the trip_data table needs to be added to QGIS. Click Add Delimited Text Layer again, browse to the trip_data table, and choose “No geometry” next to Geometry layer definition. Press ok. The table is added to the Layers list in QGIS. Right-click the table name in the Layers list and click Open Attribute Table. You can see the data has loaded correctly. Notice that the station_id is used in the Start Terminal and End Terminal fields.


The average duration of a trip from each station is a good first analysis. To get the average duration we have to total up the durations of each trip by Start Terminal. This could be done in a spreadsheet program, exported as a CSV file, and then added into QGIS using the steps described above for loading non-spatial tables. Alternatively, we are providing, a script created that will do the calculation within QGIS.

In the Processing menu under Options and configuration, expand Scripts and view the folder path. This is the folder path in which to save the Python script. Once the script is saved to that path, restart QGIS.

Open the Processing Toolbox by clicking Processing > Toolbox. It will appear on the right-hand side of the QGIS window. Expand Scripts, Boundless, and double-click “avg.” Fill out the dialog with the following, making sure to save the table as a CSV file in the path of your choosing.


Now you can join the output table with the station data layer in order to visualize the average duration (in seconds) of trips from each station. Double-click the station_data layer in the Layers list to bring up the Properties window. Choose Joins and click the green plus sign near the bottom of the window. Pick the table from the list that contains the average data and the field that has the station ID number. If you used the QGIS script, these will be “output_table” and “class.” The Target field is “station_id.”


Now you can look at the attribute table for the station_data to make sure the join worked properly. If it did, the fields from station_data are now in the table. (If the fields are added to the table but the cells are populated with NULL values, the wrong id field was used in the join process.)

To visualize the duration field, double click the station_data in the Layers list to open the Layer Properties and choose Style. Choose Graduated, output_table_avg for the column to style, and change the color in the color ramp as per your preference. Change the mode to Natural Breaks and press ok. (Choosing a mode that makes sense for the data and for the map is an important part of the analytical process. Here is more information on modes).SmallScale1.png

Zoom in to the denser section to see that data more clearly. Enlarge the circles by double clicking station_data, Style, click the change symbol button and change the size to 3. Click OK twice.


The trips in San Francisco appear to be shorter than the trips in Redwood City. Hopefully this tutorial on using QGIS with the Bay Area Bike Share open data provides a springboard for contest entrants. Good luck!

Interested in QGIS? Learn more at the first QGIS user group meetup in the United States on Friday, April 11!