Posts Tagged ‘geoserver’

Interview with MarineMAP Mashup Developers (Kelso)

Tuesday, April 21st, 2009

marinemapsupporttool

[Editor’s note: MarineMAP is a cutting edge mashup built using PostGIS, GeoDjango, Ajax, Flash, OpenLayers, GeoServer and MapServer with Google base map tiles. It assists stakeholders in the design of MPAs (Marine Protected Areas) in mapping oceanographic, biological geological, chemical and human dimensions of the ocean and coastal areas. I talk with Will McClintock and Chad Burt of the Marine Science Institute at University of California at Santa Barbara about the technical underpinnings and development philosophy behind the project. One key to the project’s success (rolled out Dec. 2008) has been the hiring of dedicated programmers to implement design ideas and new technology to extend an earlier version’s usability and reach. Thanks Melissa and Sebastian!]

Interact with the MarineMAP at marinemap.org/marinemap.

Interactive Map Tool Objective: MarineMap is an internet-based decision support tool that provides the capacity for the SCRSG (South Coast Regional Stakeholder Group) to view data layers, create individual MPA concepts, assemble collections of individual MPA concepts into MPA arrays, receive basic feedback on how well MPA concepts and arrays meet guidelines for MPA design, and submit MPA arrays to staff as MPA proposals. This tool will be the primary way in which MLPA Initiative staff and SCRSG members capture and store information regarding MPA proposals.

marinemapsupporttool2

(Above) Screenshot above showing Marine mammal and Nearshore habitat layers on base map with area Measurement Tool enabled.

(Question) Kelso’s Corner: What technologies are leveraged in MarineMAP?

(Anwer) MarineMAP: We’re not using ArcGIS at all, save for cutting map tiles (using ArcGIS Desktop and Arc2Earth) and, as a non-critical component of the system, ArcSDE / SQL Server. We’re mainly using PostGIS, GeoDjango, Ajax, Flash, OpenLayers, GeoServer and MapServer and will soon switch to the Google Earth API.

We are using OpenLayers, rather than the Google Maps API for our “slippy map”. OpenLayers is pure javascript, as is most of the client application. We are using Flex, but only for the charting component. [Editor’s note: OpenLayers is using the Google Maps tiles.]

(Q) Kelso’s Corner: How many programmers do you have on staff to deal with all the software components?

(A) MarineMAP: Currently, two of our developers work full-time on MarineMap, while our other two developers work half time. We also have several GIS analysts and a cartographer to deal with the data end of things. We are now looking for a full-time, in-house Assistant Web Developer to continue working on MarineMap. As we extend MarineMap to different geographies and planning processes, we anticipate that we’ll be looking for one or two more programmers as well.

(Q) Kelso’s Corner: What was the rational for doing this substantial map development in house? Did you evalutate other routes, consultants, off the shelf software before going this route, why was this option preferable? Did you have a good cheat sheet for how to develop / implement this technology? Did you have to hire new staff to do the programming or did you have existing expertise to draw on?

(Anwer) MarineMAP: We did not have a cheat sheet for how to develop / implement this technology. This was a brand new application using some new technologies, and some that we were familiar with. Of course, we had experience developing other applications and some of these technologies overlapped. But, there was a significant amount of learning happening for all of our developers.

The MLPAI is an on-going process that will terminate sometime around 2011. Until then, we need to have a highly functional and stable application that can be adapted to the changing needs of the process. It turned out to be much more cost-effective and time efficient to hire in-house developers to work on the application year-round. Before we built our team, we spent a significant amount of time considering a host of alternatives, including trying to maintain and tweak Doris, contracting out all of the work, etc.  Initially, we felt we did not have enough in-house expertise. Although we already had Chad Burt (UCSB), Jared Kibele (UCSB), Tim Welch (Ecotrust) and, now, Ken Vollmer (Ecotrust) as our in-house crew, we eventually contracted two developers from Farallon Geographics (Dennis Wuthrich and Alexei Peters) for a limited period to  help with developing the database schema. This was particularly nice given that we had only 6 months to get the first version of MarineMap out the door. Dennis and Alexei are no longer working on the project but I am very grateful that we had access to their time and expertise during the initial phases.

(Q) Kelso’s Corner: What was Doris?

(Anwer) MarineMAP: At the beginning of the Marine Life Protection Act Initiative (MLPAI), staff chose to hire consultants to build an application (eventually called “Doris”) that was built on ArcGIS Server 9.1 technologies. It shared some of the features of MarineMap, including drawing MPAs and arrays, and generating reports on what was being captured inside those MPAs. Doris had a poorly designed interface and, perhaps more significantly, it was dreadfully slow. Consequently, few stakeholders used it. Furthermore, because the application was built using technologies with which we had no particular in-house expertise, and because these technologies were proprietary, we had a difficulty updating the application or tweaking it on the fly. (I had been running ArcSDE / ArcIMS and ArcGIS Server applications for a couple years but had no real development expertise in, say, ArcObjects, or VB .Net.)

(Q) Kelso’s Corner: It seems there are many more RubyOnRails developers than Django. Have you found this a hindrance for hiring staff or when looking for trouble shooting advice?

(Anwer) MarineMAP: It does seem to be a bit of a challenge finding Django developers, particularly those that can / will work locally. I have not tried to hire a RubyOnRails expert so I have no direct means comparison.

(Q) Kelso’s Corner: Why will you be switching to the Google Earth API? Is this only for the front end? Have you been happy with GeoDjango?

(Anwer) MarineMAP: GeoDjango has been fantastic. Using the Google Earth API does not mean ditching GeoDjango. Rather, using the Google Earth API represents a shift away from the OpenLayers API. We’ll still be using GeoDjango extensively.

[Our lead developer] was a big proponent of RubyOnRails for quite some time, but Django has taken many of its best ideas to Python. While Ruby is aesthetically a beautiful language, Python is usually much faster and has a more mature set of modules to build on. The only thing I miss after switching over to Django is the database migrations Rails offers. Most open source GIS packages also have bindings for Python, where as there a few similar tools for Ruby.

Switching to the Google Earth API will just mean replacing OpenLayers. OpenLayers is a very good library, but the Earth API is much faster due to the fact that it is a compiled plugin rather than being written in javascript. This allows it to display thousands of placemarks on screen at once, which is one of the primary reasons for switching. Google Earth can also display temporal and 3d data.

(Q) Kelso’s Corner: Besides the change to Google Earth API, what other changes, updates do you plan for this online map?

(Anwer) MarineMAP: Besides switching to the Google Earth API, there is one major upcoming update to MarineMap. Specifically, we will be implementing a map-based (i.e., location based) discussion forum. Users will be able to zoom into a location on a map and tag objects (MPAs, data, places) with a comment. Other users will see these comments (if they have comments “turned on”) as they zoom in to a location or if they load an MPA. Users can then participate in a dialog via a traditional discussion forum that is linked to the map. Furthermore, users will be able to define a geographic region and subscribe to RSS feeds (using GeoRSS) for any activity within that region. One might choose to do this, for example, if they want to be notified by email any time somebody draws a new MPA in, or makes a comment about a data layer in a specific region that he / she cares most about. I believe the map-based discussion forum will go a long way in facilitating discussion about MPAs, particularly outside the in-person monthly stakeholder meetings.

Conclusion: Thanks so much for the informative Q&A session. Please check out the MarineMap project at MarineMap.org/marinemap.

LimeWire Creator Brings Open-Source Approach to Urban Planning (Wired Mag)

Wednesday, February 25th, 2009

[Editor’s note: Open Planning Project leverages P2P networking to make urban transportation safer, faster and more sustainable.]

Republished from Wired.
By Eliot Van Buskirk
Email

Originally published January 30, 2009

Mark_gorton

Entrepreneur Mark Gorton wants to do for people what he already helped do for files: move them from here to there in the most efficient way possible using open-source tools.

Gorton, whose LimeWire file sharing software for the open-source gnutella network was at the forefront of the P2P revolution nearly a decade ago, is taking profits earned as a software mogul and spinning them into projects to make urban transportation safer, faster and more sustainable.

You might call it a “P2P-to-people” initiative — these efforts to make cities more people-friendly are partly funded by people sharing files.

That’s not the only connection between open-source software and Gorton’s vision for livable cities. The top-down culture of public planning stands to benefit by employing methods he’s lifting from the world of open-source software: crowdsourced development, freely-accessible data libraries, and web forums, as well as actual open-source software with which city planners can map transportation designs to people’s needs. Such modeling software and data existed in the past, but it was closed to citizens.

Gorton’s open-source model would have a positive impact on urban planning by opening up the process to a wider audience, says Thomas K. Wright, executive director of the Regional Plan Association, an organization that deals with urban planning issues in the New York metropolitan area.

“99 percent of planning in the United States is volunteer citizens on Tuesday nights in a high school gym,” Wright says. “Creating a software that can reach into that dynamic would be very profound, and open it up, and shine light on the decision-making. Right now, it becomes competing experts trying to out-credential each other in front of these citizen and volunteer boards… [Gorton] could actually change the whole playing field.”

Portland, Oregon has already used his open-source software to plan its bus routes. San Francisco, whose MUNI bus system is a frequent target of criticism, could be next to get the treatment. Gorton says he’s in talks with the city to supply transit routing software for MUNI that will do a much better job of keeping track of where people are going and figuring out how best to get them there. San Francisco “overpaid greatly” for a badly-supported proprietary closed-source system that barely works, according to Gorton, putting the city under the thumb of a private company that provides sub-par support.

“They’re frustrated and thinking about replacing it completely, and see the value of open-source because then they won’t have any of these support problems,” he said. “And they won’t be constantly at the mercy of the private companies that have these little mini-monopolies.”

Streetblog_sf_ill_4

The Open Planning Project (TOPP) was Gorton’s first foray into urban planning, in 1999. It initially involved an ambitious plan to use open-source software to model public transportation and traffic systems in large cities.

“I was much more naive at the time,” he said. “I thought, ‘I can make software. I’ll go build an open-source traffic and transportation model, which will show how much better things can be, and then go magically adopt those solutions.”

But humans can be harder to program than machines, and sometimes a human-to-human interface works best. “We’ve actually been incredibly successful transforming policy in New York City without any models at all,” he added, though some residents complained about parking spaces morphing into bike lanes.

The quest to bring open-source software to real-world urban planning continued, following the clearance of a key hurdle: Before you can build a transportation model, you need to know where the roads are.

While public, that data was locked by private software used by public organizations and suffered from an overall lack of standards. Thus was born GeoServer, an open-source, Java-based software server that lets anyone view and edit geo-spatial data. Road information can now be painstakingly imported once from proprietary systems or entered from scratch, double-checked by other users, and rolled out to anyone who needs the data.

“It didn’t really exist before,” said Gorton. “Most of the data was run on software from a company called ESRI. Government agencies have this data, but it’s all running on proprietary systems and you couldn’t get access to it, or it was very hard to get access to it.” GeoServer now runs in thousands of places around the world for all sorts of reasons, according to Gorton, whenever an online app needs to know where roads are.

Continue reading at Wired magazine . . .

Open Source GIS Stack (Mikel Maron)

Sunday, November 16th, 2008

[Editor’s note: If you want to stay away from Google, Microsoft, and ESRI to get your interactive, online map on, here’s how. Also check out this interesting PDF article on GeoDjango.]

Republished from Brainoff.com on Oct. 31st, 2008.

There’s a need for a good, high level description of the alternatives within in the “gently settling” stack of open source geoweb application development.

The OpenGeo Stack is the epitome of clarity, breaking down their tool set in a nice executive summary. But the OpenGeo stack only covers their tools, not all the available options. So I’m going to make a quick first pass of a high level overview. It’s useful for me, maybe for others. If you think I’ve done a poor job, help improve it in the comments, or on some wiki somewhere.

OpenGeo breaks things down into FrontEnd, Tiling, ApplicationFramework, Database. I’ll add Rendering, since in other tool sets this is split into different packages.

FrontEnd
the slippy map

* OpenLayers the Ajax gold standard
* ModestMaps for mind blowing Flash, ala Stamen
* Mapstraction don’t want to tax your mind? it looks just like the Google/Yahoo/Microsoft API

Tiling
be nice to your database or WMS and cache map images into tiles, just like Google and friends

* TileCache simple bit of python
* GeoWebCache same thing in Java
* mod_tile it’s kinda OpenStreetMap specific, but an apache module is a good idea too

Rendering
make pretty maps

* Mapnik looks beautiful. getting somewhat less painful to install.
* Mapserver does it all. also a pain to configure. looking better.
* GeoServer

ApplicationFramework
where the the main logic of the app goes. MVC. CRUD. etc.

* GeoDjango making great progress on a complete package.
* GeoRails more a bunch of plugins than a package, but definitely useable
* GeoServer the standard for open geo standards. Java.

Database

* Postgres + PostGIS
* MySQL sure, it has spatial extensions too. just not as fast or fully implemented as PostGIS

Random notes, other good sources

Architect your interfaces on Geo RESTful services. Andrew breaks down the formats and approaches for Neogeography and the GeoWeb in this presentation and book. For Ajax smooveness, use jQuery or prototype. Paul Ramsey has a good deep overview of open source GIS. Mecklenburg County GIS is a nice example of an instance of the stack.

There really is a need for a new book on this stuff, the O’Reilly trio of paper geo titles are great but out of date, and the landscape of osgeowebappdev is stabilising. Of course, no one wants to write it.

Take Control of Your Maps (A List Apart)

Monday, May 12th, 2008

(Reprinted from A List Apart. Thanks Peter! Paul Smith is is a co-founder and developer at EveryBlock, see this blog post. He has been creating sites and applications on the Web since 1994. He’s also co-creator of the Election Day Advent Calendar, and a founding member of Friends of the Bloomingdale Trail. He lives in Chicago, Illinois.)

by PAUL SMITH

map a list apart

We live in the era of Google Maps. What started off as an impressive refresh of Mapquest-style maps now fuels web mashups. With APIs official and unofficial, Google Maps is simple enough for front-end designers to embed and for back-end programmers to target. Along the way to becoming nearly ubiquitous, it has played a major role in the “democratization of mapping.” For the practical developer who wants to add geospatial information to a site or application, the Google Maps API has been an easy call.

But, perhaps no longer. As websites mature and the demand for geographic applications grow, the old mashup arrangement is starting to chafe. Mapping components are more and more vital, and so we demand greater control, expressiveness, and functionality from them.

Fortunately, as in many aspects of internet technology, an ecology of open source online mapping tools has emerged alongside the market leader. It is now possible to replicate Google Maps’ functionality with open source software and produce high-quality mapping applications tailored to our design goals. The question becomes, then, how?

Continue reading how to create a custom web map . . .

— And skipping right to the conclusion —

Conclusion

One of the great things about online mapping is that it straddles the line between the artistry and communication of cartography, and the precision and programmability of GIS. You can produce great-looking maps that are highly functional and integrate smoothly with your application. It’s my hope that this article demystified the web map stack and will get you thinking about how you can take control of the maps in your site.

RESOURCES/EXTERNAL LINKS

There are many open source projects related to online mapping and GIS. This article touched on these:

In addition, just to name a few: Modest Maps and Mapstraction are browser UI libraries similar to OpenLayers, in Flash and JavaScript, respectively. GeoServer and MapServer are alternatives to Mapnik in the map rendering department. You owe it to yourself to investigate these alternatives, as they each excel in different ways and one may meet your needs better than the others.