Geoserver And Architectures of Participation For...

MALE SPEAKER: Thank you all very much for coming to Chris's talk today on the GeoServer project. I'm going to let him talk mostly about Geoserver and go into this, really, without further ado. I don't actually know Chris that well, so I don't have all that much to say, but he's great guy. I met him-- he was in Africa, a Fulbright Scholar. We met when I was in graduate school over the internet, and I was using GeoServer Awesome product. We funded the KML 2.1 streaming portion of it, and I think Chris is going to talk about-- sorry, we funded the 2.0. He's going to talk about the 2.1 streaming. So without further ado, Chris Holmes. CHRIS HOLMES: Hi everyone. My name is Chris Holmes. Thanks, all, for coming out. It's great to see so many people. I wasn't expecting this. So I work for the Open Planning Project, which we'll get to. I'm also the chair of the project steering committee for GeoServer, and I'm also serving on the board of the new Open Source Geospatial Foundation, which is an exciting new project a bunch of Open Source groups are collaborating on. So the overview of the talk, we're going to have an introduction to GeoServer. We're going to talk about Geospatial Open Standards a bit, and in my first run-through, I kind of stuck them all at once, but what I'm doing this time is sort of integrating with GeoServer and Google Earth, and sort of how we leverage standards to interoperate with Google Earth. And then talk about a bit of the future, sort of towards a collaborative Geo Data. This is the topic near to my heart, and where we're looking to put a lot of efforts, but still very speculative. So the Open Planning Project. The URL is up there. We're a high-tech nonprofit based in New York. It was originally touted by Mark Gorton, it's part of the Lime Group which is a bunch of different companies. Lime Wire is the one you might have heard of, but he does brokerage firms and hedge funds and whatnot, and this is kind of his philanthropy of giving something back. And it's cool. He's definitely sort of an involved funder, and comes up with ideas, and is a core part of it. So our mission is TOPP builds technology to enhance the role of the citizen in democratic society. We have three projects going right now. OpenPlans is basically-- we call it sort of source forge for open democracy. It's a tech talk in and of itself, so we'll stop there for now. New York City Streets Renaissance Campaign, which is kind of more traditional advocacy, getting people to imagine what New York could be, and get people to advocate for nicer streetscapes and less traffic and the like. And GeoServer, which is the topic of the talk today. So TOPP's approach, we kind of think of ourselves as a hybrid between a nonprofit and a business. On the nonprofit side, we have a socially conscious mission and nonprofit tax status, but we run it more like a startup. There's a big initial investment to incubate these ambitious projects that we're looking to make a difference. And just like how a venture capital would go after projects, we're starting a bunch of projects and seeing what has a big role to play. So if these projects are popular, and really kind of explode the way Mozilla sort of has, then we want to find socially conscious business models, so that we're not just existing and some donor year after year giving us money. But these should prove their own value. And then if there is additional profit, we want to reinvest that from successful projects into starting even more cool innovative stuff. And similar to Google, the philosophy is really find and recruit these really top people, and just treat them super well and let them go. So our goals, we want to make tools to enhance government transparency and provide opportunity for citizen participation in shaping society. And a lot of this we sort of see as bringing this root open source philosophy to other domains. Geospatial was our hit on just this idea of collaborating on maps, work on the source code of maps and bring people together, collaborate instead of just one person providing it all. Politics is the sort of Open Plans Project, and get people to communicate, all those sorts of tools you saw on the Dean campaign. We want to make those even more accessible, and get people to see that the way the world is not given, that it's permeable, and that you can motivate for change, which I really think is the core of open source as well. The software package is not given to you. You can change it and suit it your needs, and make a world that you want to live in. And urban planning with the New York Streets Renaissance Campaign. One of things we did was we had these Photoshopped streetscapes of what the street could look like, and it's this idea of, you know, this city isn't a given. We can motivate for change and change our world, just like you can change open source software. And then, we really kind of want to do open source for government. Anyone who sort of thought about open source at all, it makes a lot of sense for governments. You don't have Brazil competing with the US for the best license plate software. These things they can share across each other, but governments sort of lack the wherewithal to really start their own open source projects, and I don't think you really want a government being the ones who are running the open source project. And we want to sort of be a group that can start new projects and build and grow communities around them for the benefit of governments. So the first of these projects was GeoServer. It started about four years ago, and it's an open source server to publish and edit Geospatial data. It has strong support for Open Geospatial Consortium, OGC standards including WMS, WFS, Filter, and SLD. I'll hit on those terms a bit later. And the big thing it does is really this middleware translate layer. You have government agencies already gathering a bunch of different data, commercial companies, but they all keep it a bunch of different formats that's inaccessible to the wider web. So we really are sort of middleware to connect you from your existing stuff-- we don't make you buy a whole new system and convert to the latest, greatest thing. We'll read your formats and stick it out on the broader Geospatial web. And you'll output in a bunch of different formats. There's not one huge standard format like HTML yet, but there's definitely some emerging. So we output GML Shapefiles, KML and KMZ, JPEG, PNG, GIF, SVG, PDC, and it's easy to add more formats, too. As stuff gets popular, we'll look into doing that. So TOPP's GeoServer motivations as I've sort of been hitting on is really to make Geospatial information more accessible, to increase the government transparency, and we're really looking to have it be sort of a substrate. I mean, one of the original things we were interested in is sort of traffic modeling, and having these sort of open source traffic models, but we had to kind of go back one level down, because you couldn't get road data to do cool traffic models. Eventually, we want to push that, but we're contributing to and making a sort of environment of open source around Geospatial data. And our thought was really sort of-- instead of harassing public officials, like, you know, you need to open this data, you need to spend all this money-- that many traditional advocacy organizations might do, our thought is, make tools that can make their job easier. So we started GeoServer. Our focus was WFS, which is an open standard that lets you access geographic information, really lets you get at the data behind a map, the sort of source code of a map, if you will. And on top of that, you can do stuff and do analysis, and it's really about that real access to it. And just like open source, not everyone's going to check out the source code, but you want some people to be able to analyze it, and fix it, and do various stuff with it. And then the other motivation was we wanted to see if, as a nonprofit, we could bootstrap a community around it. So our original goals for GeoServer, we needed it to be supporting and advocating open standards, extremely easy to use and set up so there's no additional training costs and whatnot, connect to a variety of formats, has to scale. I mean, GIS data is huge, as I'm sure most of you know. And we really wanted to attract these outside contributors, build a wider ecology that's not just a monoculture, and we really believed that that would make something stronger than just us working on it alone would do. And I think we've had pretty good success with that, from our original goals. We're currently at the reference implementation of the WFS Specification 1.0, and working on 1.1 one now. We implement transactional and locking. We have a fully certified WMS, and I'll get into what that means in a bit. Installers, documentation, email support, but also commercial companies starting around it, connect to pretty much all the popular spatial databases, performance, work with gigabytes of data. But the thing we're really most proud of about the current success is this community. There's really a successful open source ecology. One of the things we did early on was choose to build up GeoTools, and there were other open source projects that were similar to ours that sort of built their own tool kit, but we really felt that working with the wider community would pay off and some of that community would rub off. And GeoTools was started by James McGill, who is actually working at Google now, and he always-- he was the founder, but never wanted to be the benevolent dictator. He wanted a real community around it. And we initially did a lot more contributions than we got out of it. It wasn't super far along, and it seemed kind of like, why are we putting all this effort into open source projects other than ours, but in recent years, it's paid off incredibly. We only wrote one data access format. All the rest have come from GeoTools, and it's this sort of wider community. And people know that since we're out of that, there's a real open community as opposed to just open source and license only. And we now have contributors from companies, universities, government agencies, there's Blue Sphere Technologies in Africa, Refractions in Canada, Social Change Online in Australia, Geo-Solutions in Italy, Axios in Spain, academics from Leeds and Penn State have contributed. Massachusetts GIS has done some great contributions of late, and the US Forest Service as well. And we recently formed a project steering committee, and this is a great sign for us, that there are individuals from seven different organizations all taking collective action, and that it's no longer top dictating, this is where the project needs to go, but it's in the hands of the community. And recently, we've got a nice modular plug-in architecture that makes it easier for people to build on top of it. I mean, Eclipse and Firefox and all the successful open source projects have this architecture, and we've kind of evolved to that as well. And you can build commercial services on top of GeoServer, too. So as for the future, the future is really in the hands of the community. And from the community we're seeing WCS, which is another specification that lets you get at the raw data of a raster, as opposed to vector imagery, which the WFS does. And putting rasters more in WMS, you can read Geo TIFF, and net CDF, and JPEG 2000 and all those formats, and another group is working on complex features to be able to have nested elements, and these kinds of more complex geographical notions that people are wanting to represent, and to connect that to a back end database and do complicated joins. The community is really pushing this open platform, and we want to build new, innovative services on top of that. And really, it's an open community. I encourage people to join us and help build it as Google has done. And as a strong member of the community, the Open Planning Project is still going to push our motivation. We want to make Geospatial information more accessible. And the thing we're really working on is this sort of user contribution, participation, and maintenance and creation of Geospatial data, this CBS for the Geospatial web, if you will, which I'll talk on a bit later. And we're going to continue do more of the dirty work, and put releases out, and work with new formats and just the stuff that's not as flashy, because how open source funding generally works, we can keep pushing that. And we want to work on this bigger picture of a true open Geospatial web. We want to get to the situation where citizens demand open Geodata, and I think Google Earth is really making strides in this, but governments in the past wanted to share documents and citizens might have wanted them open, but the world wide web came along and people demanded, you need to have government online. We want to see the same thing for Geospatial data, where there's such obvious value to everyone that they start demanding it from the governments. You need to get on this. You need to have your layers accessible on Google Earth. I need to see this zoning information, this transport information downloaded to my client on the open Geospatial web. So that's the basics of GeoServer. A couple words about open standards before we get to what we did with GeoServer and Google Earth. So why open standards? The big word is interoperability. Someone else can write a different server, yet the same client can talk to both servers. Different clients can talk to my server, so that you really have this broader ecology of people who work with one another. And it really spurs innovation, too, because you can build them in different ways. And the big thing is lowering the bear to entry, leveling this playing field. ESRI, they used to dominate the server market, and they didn't follow open standards, and there was this-- you could search Geospatial stuff, but only on their network and only if you bought their product. Whereas with open standards, you can get open source software, you can get commercial software, and it's easier to jump in. And really, this idea of building something bigger than any organization can alone. In the early days of the internet, there was this danger of going to the sort of Netscape web and Microsoft web. They both had browsers but they also had their own servers, and they started adding a bunch of different extensions onto them. And this would have led to this world where you had to pick-- do I want to be on this Microsoft web or do I want to be on the Netscape web, and the thing is, that would have limited the overall value of the true web where anyone can get on and put a whole bunch of information on, because they would have had to buy a server. The thing that really prevented that was the Apache server, and it had this lowest common denominator implementation of standards and helped build something far more valuable than a Microsoft web or a Netscape web. And that's a lot of what we're looking to do with GeoServer is sort of an Apache for the Geospatial web, if you will. So the Open Geospatial Consortium is the main standards body in web-based GIS. Overall, they do good work. I definitely have some issues with them sometimes. Sometimes they're a bit in need of a reality check, and I think commercially oriented organizations can start to give that to them, and they're starting to wake up as how Google Earth and KML are blowing through their GML specification. They're starting to realize, we need to actually support users as opposed to just governments. But there are some great standards there. WMS is the most successful one, I'll get into that. WFS is this sort of source code, and then SLD and filter. There's also GML, which is an XML language for geographic features that's pretty compatible with KML, but it's just focused on the actual geometries whereas KML is sort of this whole packet of styling, and view, and 3D information. And there's also WFS-Transactional that allows user collaboration and Geospatial information. So next, I'm talking about GeoServer and Google Earth. So we've done work recently to be able to interoperate with Google Earth, and I'm going to get into some of those implementation details of how we went for it, but first a bit on the motivations. From the Google site as I understand it, it's to provide a way to link existing databases of Geospatial information directly to Google Earth. There's of course the fusion server, that replicates and has this highly scalable stuff, but lots of times an organization wants to connect to their database where they're constantly doing updates and just push that out onto Google Earth, and there's this great KML format that lets you do that. So instead of-- and of course, there's KML for a format, and it's great for these smaller data sets, pass around a file, but it doesn't so much scale to the size of most Geospatial database, gigabytes and terabytes in size. And there's also-- I mean, Google thought of this and came up with networked links, which are this very powerful construct, but they leave a very heavy burden on the implementer, which kind of says, return KML based on this bounding box. And a good solution to this is an open source project in general. Have those people who want to sort their data as KML collaborate on a shared code base. And Google is smart in that they found GeoServer as, we already did the reading of data formats, the putting into a common feature program in API, and then just needs to translate that into the KML output. And from the GeoServer perspective, we wanted to give our users another option to visualize their data. We want to have it be accessible in as many different formats as possible, and Google Earth's great for making it accessible to less technical, non-GIS people who can visualize these layers that these organizations may already have, but only the GIS specialists know about. So the use cases behind this-- it's definitely not for everyone, but used for a lot of these edge cases. This primary use case is an organization that already has a whole bunch of spatial data, they have their existing servers, they've invested in Arc SD, they've invested in Oracle Spatial, and they already have the work loads in space, and they just want to expose that onto Google Earth, both internally and externally as well. So they can just stick GeoServer as that middle layer, it translates from their format into the KML. There's also transaction capabilities that are quite nice, collaborate on a shared resource. Last time I was out here I talked a bit with guys from Nature Conservancy, and they really wanted this global conservancy database of protected areas, but they're not going to be the ones to fill it up themselves. They kind of want to open it up. And with a KML file, you can definitely pass it around and update it, but as soon as you have more than a couple users working on that-- that's the whole reason that there is version control for software, for source code. You want to put in a central place, take it in and out. So it really allows this cooperation on a shared resource, and then continually output that as Google Earth. There's also this SLD specification, that really puts the sort of styling in the hands of the user. The server can sit there and exist, and you can actually change how it's going to render it and emphasize a different aspect of the data set. So the initial map may be colored in red, that emphasizes some certain aspect, and you may color different sets. And as a client, you can actually send that to the server and get that back on your Google Earth without having to set up your own server. And then we want to enable access to raw data, one can sort of zoom through Google Earth, and then you might want to download a shapefile of the area. And you can do that with GeoServer and output as different formats. And then also, connecting to remote WFS's, and then use GeoServer as your middleware to style from this open data into KML. So this is a bit of an implementation overview that I'm going to get to, but the general approach is leverage open standards and existing code as much as possible. So the root specification behind this is the Web Maps Service, and this is a restful online API for requests to get a map-- an image-- from a server. The first request is get capabilities, which is tell me what you have on the server, what layers are there, what styles are they available in, what projections are they available in? What do you have, server? And then after the client gets that, then he can request a map. And you put in a URL, and then there's a couple basic parameters. The request is a Get Map. The layers-- you can request just one layer, you can have the server compose a bunch of different layers and send it back. The styles, what's this map going to look like? There's different options on the server. The spatial projection, what coordinate system do I want to see this in? The height and the width, and the format you want to see it in, and the bounding box of the area you're looking at. So the great thing about WMS is it's really compatible with a bunch of different software. It's supported natively by a bunch of different projects, but it's also compatible with other services, and we've had some good success and others online have. On Google Maps API version 2, it allows the custom pile layers, and people soon started connecting that directly to WMS servers, so they had their existing servers, and it worked with a few tweaks to the API. And we've been supporting that in GeoServer for a while. There's a Java Script library that will hook you up with Google Maps quite quickly. And the other thing you can do is WMS is a dynamic protocol, but the cool thing is, you can stick something like Squid to do all your caching for you in front of a tiling client, and you'll get a lot of the benefits of the nice tiling idea that Google Maps came up with and made popular. The other thing you saw with Google Earth was the KML WMS reflectors. They were among the first network links to come out that really linked to some valuable data, because these servers were already out there. And all they needed to do was take that B Box request to the network link, append it to the rest of the WMS request, and then wrap it in a ground overlay, which Google Earth could then render. So it was just a couple lines of code to connect from WMS to Google Earth. And WMS allows a lot of different out formats, so there's PNG, GIF, SVG, PDF, Flash-- that's supposed to be-- so why not KML, KMZ? Why not make an open format directly? Well, that's exactly the approach we took. This is great because there's no additional configuration for GeoServer users. We can utilize the same connections and configurations they've already done, and now links can connect directly to a WMS. They just request KML or KMZ as the output format. And if you want an active region-based network link, you can just leave off that bounding box parameter, and Google Earth will send the refreshes as you set it, and add the bounding box in, and continue to get more and more data as you zoom around. And from our development perspective, we just had to write a new output format. We didn't have to rewrite the whole connection stack to support KML and KMZ network links. Another implementation thing we did was a KML reflector to make the WMS even more accessible, so you don't have to-- as you can see up there, this ladder is traditional WMS requests of all these variables, but from a user perspective, they know the layer they want, and that might be about it. And in Google Earth, your spatial reference system is set. Your height and width can be set. You can have defaults for all these variables that can go straight to Google Earth. So what we did was if you put in Add the KML Reflector, it'll fill out the rest of those WMS variables for you, but you can also customize those variables as you like, and the reflector will understand it. The other thing we do is divide up layers into each of their own network links, so if you request three or four different layers, you'll be able to get each one in Google Earth and turn it on and off. And we do nice things like set the default reloading for the camera, we set it to three seconds after it stops, send another refresh. And we also return the correct mime type, so that you can just type this into your browser, and it'll fire Google Earth up and just go. Another thing we did was chose to use SLD for styling. Now SLD is a pretty school cool specification. It stands for Styled Layer Descriptor. It's an OGC standard for styling mapping data. You can think of this, CSS for geospatial information. It's a vendor independent style sheet that works against geospatial data. And it's very quite powerful when combined with KML output, because you define it based on rules for your data set as opposed to having to set each attribute with each feature to style in a certain way, you can just say, color these things this way, these things that way. And we're already using it natively in GeoServer, so the data is already defined with SLD, and it just allows us to use those same configuration stuff. You can figure the styling once. You can view it on Google Earth, view it on your desktop GIS, view it on a 2D map as a PDF, et cetera. So this is a basic SLD. I'll use a laser pointer, although. It's a bit more complex, but basically what this says is style this green. More of the SML is used when you get these bigger requests, but this is basically, XML that just says, this is the rule. Do this. Advanced SLD gets into a bunch of different rules. So you compose your style sheet of do this for this, do this for this. You can base your rules on filters, which are SQL-ware statements, if you will, against the data set that says, limit to these features, limit to these features. And you can also do minimum maximum scales to limit the number of features, at this zoom level, portray these. At this zoom level, portray them like this. At this zoom level, portray them like that. So you can do stuff like color all streams blue. You can also say, use Road Type Attribute and say, color major highways orange, minor highways yellow, and normal streets white with black outlines. And then you can base it on the zoom levels as well. At this zoom level, draw with three pixels. Zoomed in more, with seven, zoomed in more, with thirteen. And this really lets you do thematic maps, and base your colors on quantiles and statistical analysis, and really do a bunch of different-- divide this attribute, layer this attribute, take the cosine of it, and color those blue if the cosine's less than six. That doesn't make sense, but it really has a whole bunch of power to set a bunch of rules to portray things as you will. And then you can also do user-defined SLD, and I think this is one of the coolest aspects, where the administrator is not the one that has the final say on what your map's going to look like. They may say, there's these four default styles, but a user can also define their own SLD file, pass that to the server, and the server is going to render it back to them as they want to view it. So this really opens up visualization possibilities for clients, for people just using it. And there's two ways to do this. You can either include the XML directly in your WMS request, or you can point the SLD file to a remote location. So with GeoServer and Google Earth, you can define your style as you want, pass that to GeoServer, request the KML output, and you'll get your whole map rendered as you want to see it, and have the KML output. So other things we did were, an SLD wizard. This is very basic. The point was to replicate Google Earth Pro's shapefile [UNINTELLIGIBLE] functionality, just pick the line and pick the color you want to see it. Previously, you had to actually edit your SLD XML files by hand. But this, you just click on a few things and you're good. We made it based on Ajax, so it's its own utility, independent of the GeoServer web admin system, used standardized PutStyle operations. So the goal of this is to eventually maybe make it its own thing, where it can customize other WMS servers and work on top of other clients. You could have a Preview window in that Ajax on top of Google Maps of styling your WMS on that nice base map, and then upload it to GeoServer, and you're good to go. And we hope to extend that functionality to Min Max Scale and Filter and get at this whole complexity behind SLD, but really make it easy from the user perspective. The other thing we did was a KM parameter, and this is basically-- sometimes it's more efficient to process the data on the server and send an image back as opposed to dumping all this XML. So what we do with the KMScore is basically it says, the user can say, over a certain number of features, don't send me back the information because it may be too tough for Google Earth to render. So we have the server make a 2D ground overlay, as opposed to passing that full KML. The server renders that image and puts it back. It uses the same WMS code, wraps it in-- I mean, it's similar to the KML reflector, but it's natively done as the output format. And KML 2.1 regions are another solution to this. They can help with these massive amounts of data on the server, but at the time we were working on it, it wasn't released yet. And indeed, this is very compatible with KML 2.1 regions as well. Sometimes the region still may be too big, and you want to render a flat image to the KMScore, because it's quite compatible with that. And then just a bit about the KML Writer, we leveraged our GML writer, because the two are very similar for geometries, and then we reused our existing rendering code for 2D applications and did it KML. A cool side effect of this was that we streamed directly from the database to the output stream. If you have a 2D image, you have to load it all onto memory before you send it out to the client, but with XML, you can just stream it directly. And it's based on GeoTools, which is a great tool kit in that it on the fly transfers from the database to your output format. So we actually get very low memory overhead when outputting KML, because it's this nice XML format. As for the future, we're looking into 2.5 dimension stuff, allow users to define an attribute to be used as the altitude of a feature. So you could have building heights be actually rendered into KML, and I've got a screen shot of a prototype of that. And you could also combine those with filter and do interesting statistical analysis and visualization. You know, have crime be the height attribute of different states or different counties, and it's this nice, compelling 3D visualization environment, and we can use all the filters and functions to do that. We're definitely looking to do KML 2.1 regions and SuperOverlays. Use that min max from SLD and stick that into the KML and really get that nice streaming effect, and make it much easier for people to-- they just stick in their data set, and GeoServer will do all the work of making this nice streaming thing for them. We want to expand the SLD Ajax editor, and another thing we're looking at is this native caching. Once we get into this big tiling stuff, WMS is a dynamic protocol, but what you can do if you've divided the world up into tiles, you can start to cache them. So as clients request that same area, you're return that. And we've had good success with Squid which is an open source HTBT caching solution, but it would be really nice to have a pure Java solution there as well, that we can just distribute a plug-in and not make people install a bunch of different software. And again, what you might think of. We're an open source and open community, and you can definitely join and become a part of it. This is the 2.5D prototype, this is a building layer and we're just using that height attribute to render. So the last topic is Geospatial architectures of participation. This is a topic that's really close to my heart and what I like to think about these days. And architecture of participation is this term I use for this sort of open source process. It was coined by Tim O'Reilly initially to sort of describe how open source works, but he recently has used it much more in this sort of passive way of Napster, people put their files on and they're automatically shared, which is great for this business focus of how you can leverage these architectures of participation. But my interest is still this active participation of users who want to contribute and who are actively building stuff together. It has strong roots in Benkler's Coase's Penguin. He talks of commons based peer production, and I basically take an architecture of participation to be that thing that he is talking about that results from this peer production. Weber also hits on these ideas. So my definition is that an architecture of participation is social and technical. It leverages the skills and energies of users as much as possible to cooperate in building something bigger than they can alone. The prerequisites to all this is that it needs to be open. It needs to be guaranteed to be available to everyone in the future. In software, this is accomplished with the licensing, the open source licenses. And within this architecture of participation, the chances are highest for success if you're working on something useful or that's going to be useful soon. If you view your users as your co-developers, give them responsibility and they'll meet that. Don't feel, I'm giving this to the world, but let people participate. And lowering the barriers to contributing. First time contributors aren't going to come back if it's just a huge hassle to contribute to the core. So the Geospatial web-- unfortunately, I had to cut this to get the talk down to time. Maybe we can talk about it a bit after, but I see it as sort of a world wide web for Geospatial information. World wide web is really a great example of an architecture of participation. A bunch of people collaborate, RFC's establishing the protocols, and then users start to put more and more content on it and it becomes this great amazing thing that you can then build other webs on top of. And I see Geospatial web as sort of being built on top of this root web. This contrasts to spatial data infrastructures approach, which I had never heard of before I went to Zambia, but then learned that there is this whole sub-academic field that is working for about 10 or 15 years on-- government agencies have data. How do they share it with other people? And they have these expensive catalogs where everyone fills out metadata and than they can search it. And for me, that's just not the way to work. It needs to be bottom up, and really, Google has drastically changed the landscape in this sub-SDI field, because they've shown the value. There is much more data available on Google Earth as these mash-ups on maps and KML files than has been in 10 years of governments telling all their agencies that they need to put their data online and it needs to get on there. So it's really this much more bottom-up, show the value, and then as I was saying before, citizens will start to demand even more valuable Geospatial information. So that's the Geospatial web. The thing I'm going to talk about a bit more is architecture of participation for the actual Geospatial data. And the goal is to sort of create a movement similar to the open source software movement, but around Geospatial data. You could have users correct a base data set-- your streets, your parks. But also collaborate on new data sets of value-- wifi spots, scenic views, bike trails. And this topic is really where were putting a lot of our energy as we start to reinvest as we grow successful, we want to put a lot of energy into this. It's still very minor. I mean, it is starting to happen, and in many ways, it's like the early days of the free software movement. You have hobbyists running around with their GPS's, and you have hardcore freedom people. My goal is really to have this evolve into making economic sense for a large organization, where you have large organizations on Eclipse and Linux and IBM. At some point, it makes sense for them to put energy into Linux and make it good enough for them, as opposed to continuing to buy proprietary software. I'd like to see that for Geospatial data. There's just a few large vendors of Geodata, and if all these people using it break that monopoly or oligarchy, then they can collaborate on that base data. But it needs a lot of thought and research before we get to that point. The prerequisite is, as I was saying earlier, it needs to be commons-based. It needs to be guaranteed to remain open. And for this and Geospatial, I think we really need a clear set of licenses. I mean, we have people definitely putting stuff online, but they're just not sure of the terms. I think that if there were clear licenses that were very well marketed, people would start using them more and applying them to their Geospatial data. Creative Commons is a great example of this that really has their name out there, and they could potentially be a good ally in this and boot strap onto their marketing effort. Also, I mean, they may need to be customized for Geodata. I mean, if you have a share alike license, does that mean if I add other layers that they infect those layers from my base layer, or is it just the data of one layer? Is the data copyright, is the produced map copyright, is it styles or data? I mean, there's just a lot of confusion that people don't feel confident about putting a creative commons license or what kind of license they apply to their data to make it an open access type thing. And I think it needs to be used as defaults, and creation tools, and GeoServer and KML creation tools-- what license would you like to use, as opposed to just put it out there, and no one being sure. And then, there's two sides to this, the social and the technical. On the social side, I really think we need innovations in these work flows. We have two strong models to draw on. There's Wikipedia and there's free and open source software. Open Street Map is a project doing Geospatial information on this Wikipedia model. Anyone can commit and they rely on rollbacks. But on the other end of the spectrum, we have free and open source software. And people think of it as this very collaborative thing, but I'm not going to give commit rights to my project to practically anyone. I want people who are going to be good, because if they aren't that good, they're going to break the build and it's not going to work for anyone. So there is this control within free and open source software that allows it to be open. And I think for maps, we're probably going to end up somewhere in between FOSS and Wikipedia, that letting anyone edit a map might be a bit much so some people might need rights. Another thing that I think can make a lot of strides is automatic rejection of features. You can set a bunch of rules and we actually have a validation engine in GeoServer that lets you set these defined rules, so that if someone scrolls their name in streets across the US, it'll automatically say, no. That doesn't work. Roads shouldn't be Chris Holmes in California. Also could build in peer review process and commit rights to just a certain area of the map. And I think another point how it's going to be different than Wikipedia and more like open source software is we're not going to have this one atlas to rule them all that has this one way of working. You're going to have a bunch of different projects. Some might work with some social models, a benevolent dictator. Some might be more democratic based. Some may actually work in a Wikipedia model and let people in, but it's going to be different for different data sets. I mean, you're not going to want your emergency response precise maps to be contributed by anyone in vandalizing. You want workflows in process through that. But for something like bike trails, you know, no one's going to die. Well, hopefully not. And then another thing I think we need is incentives. Why are people going to contribute? Maybe a dual licensing model, maybe some people choose to buy it outright, others agree to contribute a certain amount to get access to the data. But that's definitely an open question. On the technical side, I still come back to open standards on this, but use this WFS-Transactional. It's already a standard to edit a back end data space. You can use existing clients and their strength from this diversity. And then you can extend on the standards for rollbacks, notifications, limit commit access, et cetera. And another thing that I think is needed is this notion of a patch file. In open source software, the dictator will review patches and decide what to commit. You could perhaps use WFS-Transaction XML, and there's also the KML update tag, which is currently tacked on in front, but if you could actually send that to the server and have that maintain a reply that update to the core data set, then it can be available for all. And I think we need to allow plugable workflows, let you pick how you want your stuff to work in WFS-Transactional. Do you want automatic validation? Do you want peer review? Do you want hierarchical review? Limited commit access or make it open to anyone? Sand [UNINTELLIGIBLE], rollback, link to issue trackers, and really open the door for the social to innovate on top of the technical. And then finally, you're going to need something that's not these like full bore GIS systems that are very intimidating to people. We want these scaled down systems. There's U [UNINTELLIGIBLE] that already has WFS-Transactional, can simplify it for just GPS. Have Google Earth work against this collaboration platform, connect to the server and update instead of when you click Add A Point, it goes to a common space. And maybe you could send that KML update file through WFS-Transactional. And then Ajax applications built on top of Google maps, Submit and Edit points. A couple ideas on how to encourage this. A big one would be to make available high quality base satellite data under those share alike terms that guarantee that it's going to remain open. You could also-- I mean, you'd probably need to hold that copyright in neutral organization. You see this with all open source projects. The recent Open Source Geospatial Foundation, a lot of the impetus behind it was Autodesk wanted to open source something, but people aren't going to trust Autodesk. But they will trust in a more neutral foundation. And you see this with Wikimedia as well. People like to know that it's going to remain open, this is an entity that is guaranteeing it to remain open. You can start with public data like or VMAP, build applications on top, integrate with other stuff, but allow this malleability, have been expose this button that says Fix Me and takes them to the editor that lets them change it as they like. Integrate with handheld GPS devices, and the last idea for the next slide is a hosted service of Geodata comments. This was originally a paper by Harlan Onsrud, where he described this online system where people can upload a shapefile. An academic who you was studying bird migratory patterns and just wanted to make it available so some person in the future could also look at those patterns. And just make a few metadata calls, but in a natural human language way of, when did you gather this? What stuff is there? But in his mind, it was just this repository where I could then download that data. I'd like to extend that to a web services environment. Any one uploads their data, picks that license, but give people a compelling reason to upload it. Why should I just put my shapefile that no one's really going to use? But if I can upload my shapefile, and then suddenly have it available on Google Earth and show it to my mom, I am much more incentivized to upload that shapefile. And then you could add user contributions to this. WFS-Transactional, let people decide the commit rights. Are they going to accept patch files? Are they going to let anyone edit it, make their workflows? And then it becomes this source forge for the Geospatial web, this collaborative open projects on hosted environments. And this could really be a boon for lots of work-- in Africa I saw a bunch of aid organizations, and they would come in and do these big, expensive projects. And they'd gather, say, all the radio towers in Zambia. But their goal in it was to figure out where to put the next schools, not to just gather this base data. But if there was some easy place where they could upload that, then someone else may choose to maintain it and really get this flowing Geospatial web. So as for the future, I really see this being-- just as the world wide web is the substrate for the Geospatial web, so too, this can enable these other open collaborative webs. With the Open Planning Project, a lot of our initial interest was traffic modeling, and allow these traffic models to be shared from New York to different cities. And they just have that Geospatial [UNINTELLIGIBLE] that they operate on and run the models, but then have these ways of figuring out and collaborating on top of that. You can do urban planning and zoning information, and environmental modeling, and really, things we can't dream of because we're still establishing that substrate to build interesting stuff on top of. And I'd really like to see this more effective collaboration between citizens, companies, and government, as opposed to some people controlling it allow citizens to feed back into the process. And that's a lot of what the Open Planning Project is getting at is having citizens play an active role in the society and help fix that core mapping data, and make things of value for everyone. I'd also like to see the search and find Geospatial data sets overlay and analyze them, and even contribute back. I want to be able to search for Chicago crime maps and put that on top of Chicago Craigslist, and view that myself and turn that into my own mash-up, that you really have this web of information as opposed to just one-off applications and search and find. And the Open Planning Project, we're building GeoServer to help make this future possible, and we definitely encourage any and all to join us. Thank you. MALE SPEAKER: Is there a WFST implementation yet? Has anybody [INAUDIBLE]? CHRIS HOLMES: Server side, GeoServer does. Client side-- the question is, is there a WFST implementation? I'm not sure if he's asking client or server side, but I'll-- MALE SPEAKER: Both. [INAUDIBLE] CHRIS HOLMES: Yeah. Well, I mean, they're independent of one another. So GeoServer implements at server side already. There's U Dig, which is a desktop GIS. There's Map Builder that does WFS-Transactional in a Ajax environment. There's Commercial, there's plug-ins on top of Arc GIS that do WFS-Transactional. There's a couple other desktop programs. Open Layers is another open source one that is looking to do web mapping type things, so yes, it definitely exists. MALE SPEAKER: So [INAUDIBLE] environments is kind of a way to begin to assemble this data. So I was wondering, if this is more of a web services approach, can you just in-line, in a way, the data sources, so that if you were to go into a scene, you would really only need in the scene description to have links, and not necessarily [INAUDIBLE] the data, and then use caching and things like that to provide performance. Talking about [INAUDIBLE] barriers to entry. So if I have a data set, if I could just host it on my own server, and not really copy it out there and have to worry about publishing and distributing and things like that, really just keep it locally on my server and provide a link, then maybe that's a way to kind of deal with that? CHRIS HOLMES: Yes, so the question is-- MALE SPEAKER: Like if you in-line [INAUDIBLE] CHRIS HOLMES: What do you mean by end line? MALE SPEAKER: In line. CHRIS HOLMES: Oh, in line, sorry. MALE SPEAKER: Yeah, sorry. And you don't actually have to host it yourself, and then you can have more of a web services oriented approach. CHRIS HOLMES: Yes. So the question is, you have this in-line image thing on the web that allows you to not host your own web server, just call a different image and put it on there. And I'd say the answer is, yes. I mean, that's how it's working that you just reference a server. I mean, that's how the WMS spec works is that you're not going to host that data yourself. You're just going to have a lightweight client. I mean, at this point it needs to be a Ajax client to make those calls. We don't yet have that language in browsers to say, WMS here, but yeah, I think that's definitely the direction to go. And from a rich client perspective on Google Earth, yeah. You just put in that link. You're not hosting that. It may cache a bit, but. MALE SPEAKER: [INAUDIBLE] CHRIS HOLMES: Yeah, we definitely have. We got a nice bump in downloads. We were about 4,000 a month, and it's closing in on 7,000 or 8,000 a month. So yeah, there seems to be more interest, and did some sort of press release, and have had questions on the user list about implementing it, so it is a nice option that people have. MALE SPEAKER: Have you started any work on the 2.1 stuff yes? CHRIS HOLMES: The question is have we started any work on the 2.1 stuff? I've done a few little design documents, haven't started implementing. We're still working on really tightening up the 2.0 stuff. As with any project, you put it out there and then people find little fixes, so we're still wrapping up that and making that support very solid. But there's ideas of how to do more trivial implementations of it, of just do a bunch of WMS links, but also thinking about these better caching and better approaches that use SLD and whatnot, so. MALE SPEAKER: [INAUDIBLE] CHRIS HOLMES: What? MALE SPEAKER: Is there a link to the selections? CHRIS HOLMES: There will be. MALE SPEAKER: You have to email it to that lady. CHRIS HOLMES: Yeah. MALE SPEAKER: She can put it out there. CHRIS HOLMES: Yeah, there should be emails. I'll try to put links to other stuff I've referenced in here as well. My blog is cholmes.wordpress.com, and I'll at least put a few links up on there and link to the talk and link to the slides and whatnot. MALE SPEAKER: [INAUDIBLE] CHRIS HOLMES: Cholmes.wordpress-- do you know Wordpress? dot wordpress.com. It's just a hosted blog environment. Anyone else?