Implementing a GIS-based Safe Routes To School Route-Finding Methodology: Introduction

The Need For Safe Routes To Schools

The rapid decrease in the number of children walking to school, coupled with the equally rapid increase in childhood obesity, has made encouraging more children to walk to school a top priority for schools around the country. In 1970, half of all school children walked or rode their bikes to school. By 2009, that number was down to 13%.

So glad I don't have to drive this anymore.

Many parents cite “traffic-related danger” as a reason they won’t allow their children to walk or ride their bike to school, which leads to more traffic, and thus, fulfills their fears of a more dangerous street.

It is estimated that a quarter of morning rush hour traffic is comprised of parents bringing their children to school.

With these sort of statistics in mind, school systems around the nation have been implementing “Safe Route To School” (SRTS) programs to encourage kids and parents to walk or ride bikes to school.  One tactic of the SRTS program is to provide citizens with maps of safe and recommended routes to guide pedestrian and bike traffic to-and-from schools. Until recently, creating a walkability map consisted of getting people together who know the area and have them draw out the “best” routes to take, but as more and more schools are taking up the SRTS initiative, that methodology becomes harder to scale.

A GIS-based approach needs to be developed. One that can scale out and apply to many schools, including those with territories that combine many complex variables and conditions related to the walking environment.

Our Involvement with Portland Public Schools in their Efforts

Along those lines, we’ve been working with Portland Public Schools over the past couple of months to investigate ways to implement a GIS-based Safe Routes To School route-finding methodology. Creating such a methodology has been a much-discussed topic within the world of active transportation planning. While there is broad consensus about this need, how to satisfy it is a different story.

The first step in the project was to design an initial approach to doing the route finding analysis. To that end, we spent a good deal of time on research. Our team reviewed topical literature and interviewed local transportation experts, analysts, activists, wonks, and data stewards. Our discussions brought us to a variety of public agencies and departments in Portland and the State of Oregon, from the Portland Bureau of Transportation, to the Police, Metro, TriMet, and the Oregon Department of Transportation.

We engaged with people who work with Portland-area transportation data on a daily basis to improve our understanding of all the data available for analysis and their relative condition of completeness and accuracy.

We also wanted to get the experts’ opinions on the best approach to working with the data. The literature review was extensive, going beyond the SRTS-specific papers and into the realm of theoretical GIS analysis. Two documents, in particular, were very helpful starting points: A Data Model and Internet GIS Framework for Safe Routes to School identified a detailed data model for using street centerlines and the network source, and, A Framework for GIS and Safe Routes to School, identified datasets that would be helpful.

After Extensive Research, Our Methodology Takes Shape

After a number of interesting interviews, extensive lit review and some practical trial-and-error analysis, we have developed and refined a GIS-based Safe Routes to School route-finding methodology that we expect will be able to be scaled out and replicated for multiple schools beyond our test school. We still have some important field verification and refinement to do, but the initial results have been promising. Our methodology is broken into multiple phases.

The first phase, Data Preparation, is the most time-intensive, as it requires a number of steps to prepare source data for inclusion in a pedestrian network. In the second phase, the network is actually created. The final phase is focused on generating individual student routes and then more more general recommended routes from specified “gatherings” or “collector points” using a “closest facility analysis” technique.

The first two phases are a one-time effort to establish the network data model and the network itself. After this initial setup effort is complete, there will be on-going work related to maintaining, updating, and enriching the data used in the analysis to support ongoing improvement of the model and the results it produces.

There are different ways that one may start when creating a pedestrian network for use in Safe Routes To School route-finding. In the case of Portland, OR, we were faced with a couple of leading options, the first being to use the existing street centerline dataset and build on that, or, alternatively, to use distinct sidewalks and crossings datasets as the primary sources for development of a walking-focused network. Ultimately, we elected to use the street centerline, mainly due to gaps and suitability issues discovered with sidewalk data for this area, however, with limited modification, the same approach we have developed to apply to centerline data could used with a different network derived from sidewalk and crossing data, for instance.

Up Next: Our Recipe for Cooking up a Usable Network

I don’t want to leave you hanging, but I think we’ve covered a good amount of ground today. Join us for our next installment, where I show you a bit of the recipe that we cooked up. If you’d like, you can read about our adventures in field testing.

Designing an intuitive, User Interface

From Wikipedia, “The user interface, in the industrial design field of human–machine interaction, is the space where interaction between humans and machines occurs. The goal of this interaction is effective operation and control of the machine on the user’s end, and feedback from the machine, which aids the operator in making operational decisions.”

User interface (UI) design is a crucial aspect of software development. Without proper UI design, software - no matter how great the intention, technical wizardry, or investment behind the application - will be difficult to use and not widely nor joyfully adopted. In order to develop software that is truly intuitive and clearly answers a need, the team behind it must have a deep understanding of not only the underlying technical platform and data, but also of the people who will be using it, and WHY they’ll be using it.

At the Gartrell Group, we strive to make every application that we develop intuitive, easy-to-learn and use, and well-fitted to the understood needs of intended end users. This is consistently one of the single biggest topics of conversation and areas of focus in our company; it’s an area where we constantly self-assess, try refinements in our approach, and review industry trends and pearls from the blogosphere for ideas that might be integrated into our design practices.

Making a sweet UI; it’s not an easy task. But it’s really satisfying when carried out successfully.

Designing an intuitive and useful UI is a group effort that involves extensive communication between the client and our design team. For good design to happen, customer advocacy needs to extend from the whiteboard back to the coding station – business needs and the purpose of a software tool must guide all and be a reference throughout the full lifecycle of design and development.

OK, but how do you manage that?  People profess lots of ways and even standard methods have lots of different interpretations, flavors, and personalities.  Here’s a list of principles and practices that our team has developed to guide our work through an application development project. It’s not in order of priority. We treat them all with equal importance.

An effective user interface should be “pleasing”.

What we mean by this is that the UI should please because it looks good (it has good form, aesthetics), it simplifies complex tasks and operations (it functions well), and because it makes work faster and easier (it is tightly bound to the business mission).

View the UI through the user’s eyes.

We like to get insights early. This often means that our team will spend time with the people who will be using the application we are building so that we can develop a deep understanding of the users and their needs. We find out what their objectives are and what questions they seek answers to when they access an application.  Knowing what their workflows are, what they’re pain points are, and what is working well for them is very valuable to us and informs our UI design work.

Depend on Clients to Define the Problem, Collaborate in Designing the Solution.

This can be a subtle thing, but it’s important.  We have learned to focus our clients on describing the problems they want to solve rather than defining the actual solution.  The burden (aka creative pleasure) of solution development  is one that we should bear or at least share with our clients.  After all, we’re bringing expertise in information architecture and UI design and this is an important part of our service offering and value proposition.  By applying this to client challenges, we have developed a pretty good track record of arriving at pleasing, effective solutions – which may often be quite different than what our customers had initially envisioned. That said, users will also often have clever and thoughtful ideas about how to solve their challenges (ideas which may or may not be bounded by the standards of UI design). Often the most elegant solutions will stem from a combination of our expertise blending with the user’s articulation of their needs and their creative input.

Good design comes in iterations.

We generally start with a low-fidelity sketching or wireframing and move progressively into testable prototypes. Our development practices also proceed through cycles of presenting tools-in-progress and providing customers with regular opportunities for review, testing, and for design refinements based on findings from those activities.  There’s a lot of discussion and different schools of thought on the viability of wireframing vs. prototyping, static illustrations vs. responsive design, and so on. We recognize that different projects may be better served by slightly different methods and approaches, and so we tend to be more integrative than dogmatic in our design methods. Whichever approach we feel is most appropriate for a project (wireframes-to-prototype, straight-to-prototype, etc.), there will nearly always be cycles of design-review-revise-expand-review.  Our team will work closely with the client team on every step of the process; presenting and discussing the iterations as the design process advances. Design work, for us, is concentrated at the front end of a project, but there are elements of design refinement that parallel and weave into the whole development process.

Model everything.

The UI is the face of a larger, integrated system involving data, backend technologies, and users. We find that modeling and illustrating the relation
ships and connections between the different components of a system is very beneficial to UI design – it’s a good technical reality check, another way of making sure key needs are being addressed and considered at all levels, and a means of assuring your system is staying true to mission. Our solution architecture work tends to involve three core model types:

• A system model will give a clear understanding of the logic and rules of the system. Our solution architects will work closely with the client’s technical team to ensure that the data relationships are correct.
• An interface model will show how the system is presented to the user through its UI. This will show how the user works with the underlying data and technology via the UI.
• A user model will show how users will interact with the system. Different users will have different interactions and needs. We try our best to model each user’s workflow so that we may design optimal ways for them to accomplish their objectives through interactions with the software tool.

Delivery team communication is critical.

It’s critical that communication about what can be drawn vs. what can be rendered in technology with ease and positive effect be an ongoing dialog.  The design work cannot be done in a vacuum, it needs to be shaped and constrained in certain ways by technical standards, and technology needs to be bent to and shaped into design.  There is always a tension here – we have organized our practices with the goal of keeping it a healthy tension.  One way to do this is to have a rational sequence of design and build subtasks.  Ultimately important, though, is to have regular check-ins, internal reviews, and discussions to confirm that the pieces of a software solution will “click” together happily and all the way through a succession of design and build cycles.

Test, test, test.

Testing can reveal possible UI needs that were not understood while the application was in development. It happens:  we may think a particular UI approach will work well when it’s in sketch form or presented as a lightweight prototype, but then realize through testing that it’s not going to be a fully satisfying solution. This is actually a good thing – or at least better when learned up front than after rollout.  Our goal is to have clients testing early and often — as soon as possible — so that we can see what works and what doesn’t. Even with focused effort on design, the reality of using a tool can reveal opportunities for adjustment and refinement that will make it even better. Testing can also help reveal discrepancies between web browsers (we’re looking at you Internet Explorer) and platforms. With the rise of mobile computing, we need to have a good understanding of the means by which our end users will be accessing the application and testing across all of them.

Be willing to learn new tricks

This list is ever evolving and changing – just like the methods and means behind software design and development.  Software design is a dynamic space.  There are always cool new tools and ideas emerging that continue to improve our capabilities to more closely and effectively match user needs to software functionality.  As may be evident, we are not settled and staid in our own methods and we enjoy participating in the discussion and movement of the ever evolving ‘best practices’ of design work.

The NINE Commandments of being an Innovative AND Sustainable Organization

“Innovation” and “Sustainability” figure prominently in the tag cloud of business speak. Many of our customers across a variety of industries are contending with questions that center around the idea of inculcating a culture of innovation and selecting technologies that are consistent with the principles of sustainability. In places where both of these topics are trending, the question sometimes arises about whether being innovative and sustainable are mutually incompatible.
Is it possible to establish, maintain, and advance a sustainable technology platform AND to support and promote innovation?

Unequivocally yes. The well-balanced blend of technological innovation and sustainability is fully realized in certain organizations, it’s an emerging condition in some, and it’s an objective that is being defined and targeted in others.

When people start to ask questions like this, interesting things are about to happen. The prospect of change is at the door. Based on a collaborator’s first-hand view of how these dynamics can intertwine, and without further adieu, we offer you the NINE (because ten would be over-assuming our place in the universe) commandments of being an Innovative AND Sustainable organization with regards to your use and adoption of technology.

1. Thou shalt leap from a solid platform
Method is important. Knowing your basic toolkit is important. The efficiencies brought by new tools will tend to be markedly greater when they are being added to an existing toolkit that is used with a certain degree of mastery. If your tech platform is in chaos, you’re leaping from a water bed. Solidify the fundamentals, then to innovation.

2. Thou shalt be a scribe and reporter of thy work
Strive to be a self-documenting organization.

Documentation? For reals?

Yes. Documentation that will be done after something is done… never gets done. Documentation is not a separate task. It is a parallel practice to every significant activity and endeavor. It is a means of socializing and actively communicating in real time. Journaling is a feature of leading innovators, both because it solidifies standard operating procedures and because it highlights and promotes innovative ideas, changes, and approaches to doing better. This is a vital practice for weaving sparkly new tinsel into your nest – strengthening the old with the new.

3. Thou shalt promote a spirit of inquiry
Make inquiry and personal exploration a part of your organization’s culture. It’s a job requirement to share what you’re looking into, why, what you’re finding. Allocate time for researching and communicating about it. Companies such as Google, Hewlett-Packard and 3M have used this practice with success. GMail, ink-jet printers, Scotch-tape and Post-It notes are the result of such policies.

4. Thou shalt share
Keep the lines of communication open. Use whatever method works best for the culture of your organization; whether it’s stand up meetings or a team wiki – or both. As often as not, different departments at a single organization are totally unaware of the fact that they share identical problems or are concurrently working on solutions to the same problem. Find a way to regularly communicate and collaborate with colleagues in other departments. Keep crossing boundaries until they are scuffed and fading. You’re all on the same team.

5. Thou shalt integrate
Back up your data. Good? Now promote it. Tell others what you’ve got, what’s in it, where it comes from. Ask what they’ve got. Tell them what you wish you could get. Give it away, give it away… Make your data as interoperable and accessible as possible. There is hidden treasure on your file server, on the H drive in environmental, in the Denver office, in your CRM, in the next cubicle over. Easing the exchange of data is low hanging fruit that many people walk past blindly every day. Some of the most powerful change may come from a second look at what you already have.

6. Thou shalt know when to hold’em and when to fold’em
Standardize your decision-making process so that you can quickly and efficiently assess the value of personal exploration and research. Be decisive about whether to continue, elevate or abandon. If you decide to continue with an initiative, provide the proper support. Develop some structure for how to further assess and then begin to integrate technology and ideas that continue to show promise as they pass through the gates of scrutiny. At a certain point, questions about the fit with or extension to your existing technology platform and workflows should be applied to a return on investment analysis of proposed changes.

7. Thou shalt always keep the organization’s mission in mind
Innovation is a wonderful thing, better yet when it actually serves the needs of the organization. Sometimes people can lose focus of the organization’s goals as they are working on something new and exciting. At a certain point, people should be gently challenged and then increasingly challenged to connect a new approach or tool set to the core mission. What strategic objective does this support? How does this fit into our existing methods of work and tech toolkit?

8. Thou shalt embrace change
Change happens, constantly. The point of innovation should be to make change easier, to direct it, speed it, and make it more productive.

9. Thou shalt know that this list is not for all
Seriously. Not all organizations need or want to be innovative. “If it ain’t broke, don’t fix it” is a phrase that’s stuck around for a while for good reason.

Fear of lightning hastens the conclusion of this blog post. There are surely other key points that could have been added. But this is a good start for two cups of coffee. We hope you find some value and are maybe inspired to share some ideas that you think are successful. We welcome comments!

If you’d like to talk to us about how we can help your organization, please feel free to contact us.