Who self-identifies as a manager? So what are the rest of you people doing here? OK, so I figured there'd be some of this. There'd be managers by proxy, getting the arguments to bring home. This is not open source for managers. This is PostGIS for Managers, just fairly specific.

But there's a real constituency for this kind of topic, this kind of talk, I think, amongst decision makers who are considering getting their feet wet with open source, who have started down the road, but maybe they're still uncertain about experimenting with something as mission critical as their enterprise database. So I'll let you in in a quick, dirty secret.

At least one of my points will involve recommending engaging either the company I work for or one very much like it. So I've decided that in order to avoid any appearance of conflict of interest, I'm going to precede all my blatantly self-serving advice with the invocation of the Hypno-Toad. All glory to the Hypno-Toad.

And since I already invoked the Hypno-Toad, I might as well go and do my self-serving biographical details. So who is Paul Ramsey? I'm the PostGIS project co-founder, PostGIS steering committee chair, and a PostGIS developer. So the features that I sort of say, these are my

features, things like geography, point cloud, the linear referencing work, the circular geometry, curvy geometry, that's the stuff I worked on primarily. And I'm here all week, so feel free to ask me any questions about PostGIS. So as an audience here for PostGIS for Managers, what kind of folks are you? How many of you would describe

yourselves as managers? Only a few. What kinds of questions are important to managers? Probably not language of implementation or SQL analysis tricks or library dependencies, more practical things like from an organizational strategy point of view. What is this thing?

And can it do what I need in general terms? Who else is using it? And assuming I go forward with this, what's the plan? What's the plan of action? So to start off, what is this thing? Or as Gary Coleman might put it, what are you talking about, Ramsey? What is this PostGIS thing anyhow?

It's just a great big cylinder. It's the place you store your data. Everyone understands the cylinder. It's also the thing that answers questions about your data, like what's in this polygon, or how far is this from the store? But perhaps it's better to reason by analogy, as Oracle is to PostgreSQL, Oracle Spatial is to PostGIS.

A spatial database is just a database at heart, but with some extra goodness added for dealing with spatial data and queries. So PostGIS takes plain PostgreSQL and adds types, like geometry and geography, and functions, like area and union and buffer, and indexes, like

rtrees and geohashes. And once you have these extra pieces in your database, these types, functions, and indexes, your database becomes less ordinary. It can do new and wonderful things, like do GIS queries in the database. So generate a list of neighbors to notify. Calculate the average drive time of the truck. Summarize parcel areas by zoning. You name it, you can do these GIS things.

And unlike GIS files, databases are built to maintain data integrity under right load for multiple sources. So no passing files around, more integration with other real-time systems. And also unlike files, databases expect to be asked to handle large databases, large volumes of data, and large workloads with aplomb.

And really, all the awesome things about PostGIS are also awesome things about other spatial databases, too. They all let you answer GIS questions. They all break away from the tyranny of files and file-oriented tools. They all handle big data sets efficiently. But is PostGIS in the same league as those other databases, as the SQL servers and Oracles of the world?

So let's take technology. Let's talk about raw capability. Let's get our nerdy on. So rather than just talk about what PostGIS can do, which is a lot, people can find it more convincing when I put it next to the leading commercial brand, which is, let's face it, Oracle. So here's a quick, and I'll try to do it as quickly as

possible, but thorough feature comparison. So both databases support basic geometry types, as defined by the OGC. Both support arcs, as defined by ISO. But Oracle supports some fancy kinds of arcs that CAD folks use. They both have similar support for storing and retrieving 3D volumes. And you can see more of PostGIS 3D in a talk being

given later in this week, on Friday, by Olivier Cortin about GIS goes 3D. Both databases store geometries with more than two dimensions. So you can have a z dimension and a measure or m dimension. And both can index geometries over all four dimensions. Oracle has a quirky annotation type, which is,

again, for CAD program support. Both databases handle geodetic coordinates, latitudes and longitudes natively, though the implementation details are slightly different. Both have indexes and functions that support geodetic coordinates. Oops, where am I? Coordinate system. Both of them support coordinate systems and reprojection in the database.

They both have spatial indexing. PostGIS has some extra index types, an extra 2D-only index for higher performance. And PostGIS can do multi-key indexes, which is important for more complex queries. They both have a large collection of functions that operate on spatial data. Oracle functions have a controlled tolerance model, which is nice. PostGIS has finer detail on spatial relationships and some

really handy array and aggregation support that Oracle doesn't have. And in general, PostGIS just has more functions than Oracle. Both support nearest neighbor structures, although Oracle's is a bit more complete. But PostGIS has better utility functions around geometry manipulation. And they both have a big collection of features that are related to or built on top of or often used with

the core spatial functionality, things like topology, point clouds, raster support, geocoding and routing. So both databases can do an awful lot. And when you add it all up, the bit where Oracle does a little bit more and the bit where PostGIS does a little

bit more, you kind of have to conclude that functionally, they really aren't all that different. They have much the same functionality, but for some small differences. So from a technical point of view, getting the big nerdy on, PostGIS can do what you need. So move on to the next managerial question. Who else is using PostGIS?

And it's ordinary, human, sheep nature to feel more comfortable if a decision is validated by other folks. So let's look at other organizations that are using PostGIS. So first of all, Skype. Actually, I don't know that Skype uses PostGIS at all. But I usually like to include them as an example of

an organization using PostgreSQL at scale. People ask, does PostGIS scale? Skype. The data back end for Skype is PostgreSQL. Every call is logged. All the billing is tracked using PostgreSQL. Another example of a really big PostgreSQL installation at scale, Instagram.

100 million concurrent users all running on a PostgreSQL cluster. So you can scale PostgreSQL up to arbitrary absurd limits. Obviously, we'll never get to there. But it can be done. So size isn't something you need to worry about. It does scale. Google, Digital Globe, both big organizations using PostGIS.

They use them for similar purposes, actually. They use it to manage their collection of imagery. They don't put the images themselves in the database. But they put the image metadata in the database, which allows them to control their image preparation automation, to figure out what the best image for any particular mosaic is, to find the historical data behind a particular pixel, and so on.

When people ask me what the biggest single data set being stored in PostGIS is, I usually cite UK Ordnance Survey, their master map database. It's over 500 million records in size. There are probably larger spatial data sets now, things like LiDAR collections, and so on. But as a genuine, classic GIS data set, master map is a

pretty good example. And it's really big. Not many people have half a billion feature GIS data sets. But this is one. Ordnance Survey uses PostGIS on their web tier. So it supports live WMS rendering. It's deployed at Amazon Web Services. Not only do they use it, but a number of the customers that provide services using their data also use it.

PostGIS as a host for master map is a pretty common thing to see in the UK now. The FAA, it's a fun example. They moved all their airport management data and their notice to aviators books, all the production of those books to PostGIS, which is cool.

But the really neat thing is they were so happy with the results of doing that. The results were so good in terms of flexibility, in terms of price, in terms of customization. They set up a policy that all the future systems that they build within the FAA are also going to move away from Oracle to PostgreSQL. So as systems age out, they'll be replacing them with new

systems based on Postgres, not in Oracle. And these have all been big organizational examples, but even smaller organizations. So for example, Pierce County and Washington State have converted and enjoyed good results. They converted from SQL Server to PostGIS. And they maintain a hybrid architecture, like was talked about earlier in this session, using ArcGIS desktops for traditional GIS management analysis.

But with PostGIS to serve automated analysis in the database, and then publishing out to the web. And I already mentioned UK Ordnance Survey, but national mapping agencies in general have moved to PostGIS in a big way. They start with the web publishing space. And that's where it happens. It's interesting. You look at open source adoption.

In big organizations, it tends to start at the edges, start with the web publishing workloads, build your first web map. Maybe you start taking your operational database and replicating over to PostGIS and publishing out of that. But then working their way in, taking over existing workloads until finally the last step just becomes the obvious one. Why don't we change our enterprise

database to PostGIS? And some of the national mapping agencies have gone through that entire cycle, starting at the edge and working their way in, and actually have gone to become pure PostGIS PostGIS operations. EGN, do I have that logo? They were the first national mapping agency to adopt PostGIS for their BD uni data set.

And they've pretty much gone whole hog at this point. So how do we change? What's the plan to change from proprietary to open source? And one way is to take off and just nuke the whole thing from orbit. But it might be an emotionally satisfying plan for some of us.

It is the only way to be sure. But it's not realistic. An organization cannot cut over all its systems on one day. Day-to-day operations have to go on. Most of the staff time in an organization just can be devoted to keeping the wheels turning, keeping the day-to-day organization running.

You can really only devote a fraction of your staff to creating the systems of tomorrow. So what's the plan? What's the solution to get from here to there? One thing to get comfortable with right away is that during the transition period, there's going to be two databases running. The situation could easily go on for a number of years.

It's not permanent. But it's not entirely temporary either. It's a phase. And standing up a working PostgreSQL PostGIS database for your organization is a good first step. It gives you an existence proof. The thing actually runs. It's running right here. Joe, turn it on and it works. And it gives you a place to see how well your existing

tools can work with it. There's lots of third party tools that work with PostGIS and PostgreSQL. I can tell you that. But you really don't know it until you try it. There's nothing better than trying it and see how it works. It gives your staff a chance to actually get hands on and get the experience they're going to need as you start to migrate bigger and more complex applications.

It gives you a chance to test migrations of applications. And finally, when you go from the learning and experimenting phase to actually starting to transition, it will become one of your production databases. First it will have one app. Then it will two. Then it will have five. So how do you go about turning your Oracle people into

Postgres people? It might seem like Mission Impossible, right? The Oracle guy's been doing it all his life, doesn't want to look at new stuff. It's not actually true. Last year I got to go to the Postgres open conference in Chicago. Maybe it was the year before. But anyways, one of the things I noticed was I noticed

lots of folks, and I met them from State Farm Insurance. State Farm Insurance is headquartered in Bloomington, Illinois, so they just came up the highway. The reason why there is this delegation of like a dozen people from State Farm was that they are migrating from Oracle to PostgreSQL.

So their migration team, who are all Oracle specialists, they're all DBAs, they were sent up to Postgres open to learn new things. And that's a bit of staff upgrading. You can do staff upgrading that way. And it doesn't take a lot, because most staff recognize that learning new skills increases their value. And most staff, if they're good at technical stuff, find

learning new technical stuff interesting. If you have staff who don't want to learn new things, the problem is not the new things. And really, the transition, this transition from Oracle to Postgres, the transition from one database to another

doesn't require much learning. As DBAs, they already know most of the core concepts. All they really need to learn are new terminology, new ways of labeling things, and some details about how things are done. But they understand the core problems. They're already DBAs. They've done the hard learning. And a more extreme example, this idea of staff augmentation.

It doesn't apply to most organizations, but an example that I saw played out was that of salesforce.com, which is an Oracle shop. So they say, oh, we're a software as a service. You don't care what's underneath. But what's underneath is Oracle. And one day, seemingly out of the blue, they hired Tom Lane, who is one of the top PostgreSQL developers.

And it turns out they were tooling up to migrate their core infrastructure to PostgreSQL. And so they're a software as a service business. They've got a mission critical reliance on their core database. This is it. So having the number one expert in their employ was a big risk reducer as they're making this transition. As it turns out, Salesforce didn't end up migrating.

They used the threat of migration to dramatically improve their licensing deal with Oracle. But in the same period, they did actually purchase Heroku, which is another platform. Not a software as a service, but a platform as a service company, and Heroku has a big reliance on Postgres.

They've kept Tom on, and it probably helps them to future proof their deal with Oracle, too. The t-shirt Tom is modeling, by the way, reads, Tom Lane rejected my patch, and all I got was this stupid t-shirt. In short, minus one from me regards Tom Lane. So staff transitions, it shouldn't really be a problem. For the DBAs, the road's very smooth.

Their core skills are the same. In many ways, PostgreSQL is a much easier beast to manage than Oracle. And for the analysts and developers, moving more workflow into the database gives them access to the power of SQL. And those skills are readily acquired with a few days of coursework, and it gives the analysts a new power tool.

It gives the developers access to spatial functionality, which previously they would have required the overhead of learning a new gestalt, like GIS systems. So how do you make the plan? How do you go about eating the elephant, right? How do you eat an elephant? Take very small bites, and take lots of them. So stand up a parallel server, migrate some

applications, upgrade your staff skills, and exercise them on migrations. Keep on moving. Once you get a bit of momentum, make shutting down the legacy server the new goal. So the first goal is just can I see some stuff working? But eventually, you'll get to the point where the goal is to get rid of the old stuff. And actually, we just heard about this from the

example in Denmark. Start with some small things, and then move forward to actually the goal is turning down the old stuff. But what about support? All glory to the Hypnotoad. I thought you'd never ask. So good news. There's actually companies that exist to provide all the

things that are usually provided by proprietary vendors, the support functions, testing and integration, building out the source code from source to binary so it's easy to install and use, training services to upgrade your staff, professional services for complex stuff that you might not have the skills to do, companies that provide the assurance that the

software will be professionally maintained in the future and built for you as a customer. And the insurance that if things do go wrong, there'll be someone who you can call to help. And coincidentally, I happen to work for one of those companies. Boundless provides support subscriptions for Open Geo Suite, which is a full stack of technology for web mapping, including PostGIS and GeoServer and OpenLayers.

But we're hardly unique. There's lots of different companies that fill that kind of role. So Cloudera fills that role for Hadoop, and Red Hat fulfills it for Linux. And Enterprise DB fulfills it for plain vanilla Postgres. So we've covered all the managerial questions about PostGIS. What is this thing?

It's a spatial database. It lets you store and query spatial data just like any other data using SQL as the query language. Could I do what I need? Yeah. It can do basically anything Oracle Spatial can do. So if you need anything more than that, you're in R&D world anyways. And who's using it? Just tiny little people, academics, students, no.

Lots of big, serious organizations, both public and private, are using PostGIS for real world work. So you're convinced. How are you going to get there? What's the plan? Getting your organization into PostGIS is not a big lift. Get your development environment up. Give your staff some training. And give them some learning time. It's not just sit down in the classroom and learn.

Just here's a day to learn yourself. Try this test problem. And then migrate your applications a little bit at a time to learn and grow your skills. Because what is the alternative? The alternative to getting into PostGIS? If you don't do it, you're running afoul of the first

law of holes, which is if you find yourself in a hole, the first thing to do is to stop digging. So thank you very much. This has been PostGIS for Managers. Do you have any questions?

Is it on? OK, there we go. You mentioned Heroku in the context of PostGIS. And when we looked at it about four months ago, they had just started on the PostGIS path. So we ended up using an AWS PostGIS installation with our

Heroku servers. Any word on how that's going and the stability there? And is that looking like a good option for small? This is a startup. Yeah. I'm surprised you're saying it's only a couple months. I've been talking to the Heroku guys for a couple years. If it was cost that you're looking at?

Cost is the thing. They have kept their PostGIS on their for-pay tier. So if you wanted to run their free tier, you couldn't get the PostGIS part. So if you're willing to pay money, you can get PostGIS. If you want to pay less money, you could go now with Amazon RDS with a really small RDS image, which would probably cost you less when you're in your

development phase. And then you can just use a bigger one when you go to production. I have a question about the comparison about Oracle and PostgreSQL. Yes. Oracle has a PL SQL support, procedural language SQL.

Does PostgreSQL have similar support? Yeah, Postgres has a procedural language. It's called probably on purpose. So the Oracle is called PL slash SQL. Postgres is called PL slash PG SQL. And they are syntactically very similar,

although not identical. But if you have PL SQL skills, they should translate into PL PG SQL pretty well. You can also run all sorts of other procedural languages if you're crazy. So you can run PL Python and PL Perl. You can run PL R and do statistics right in the database. You can run PL JavaScript. I guess it's called PL V8 because it used the

JavaScript V8 engine. Pretty much any language that you want to write procedural code in in Postgres, you have a PL option. But PL PG SQL is the oldest and the traditional one. Paul, I have the same question I asked earlier, the multi-editor versioning and replication.

So in the context of the previous talk, the example given was one where an organization that was previously using files but had a copy of ArcGIS Server sitting on the shelf collecting dust stood up a Postgres PostGIS database and put ArcGIS Server on top

of it and then kept on editing with their existing workflow. And from that point of view, the versioning is there, and ArcGIS is happy to do it, and the versioning is provided by ArcGIS Server using Esri's scheme. If you're doing something different, like say all your desktop editing is with QGIS, there are some QGIS plugins that provide kind of a similar versioning idea

to the ones that Esri provides. Other than that, you start to get into interesting sort of hand-rolled or self-rolled solutions. My favorite self-rolled ones are for history, not for versioning, which are very easy to just do with

database triggers. For actual multi-user checkout versioning, probably the shortest path to having something that does that just by grabbing pieces off the shelf right now would be to use GeoGit and Postgres and the editing tool of your choice to edit your checked-out data, and use the

GeoGit process to actually manage the merging of external branches into your central database. Thanks. I'll ask the same question asked earlier too, and you mentioned curvy stuff. Curv, yes.

People around here will help me out with CAD tools. I doubt a little bit. So can you take CAD tools, do the curves, lines, and splines, and circles, and crazy stuff, and it will store if I'm using QGIS and PostGIS? No, and yes, but mostly no. So full-on CAD tools like AutoCAD have lots of kinds

of curves. The ISO specification that PostGIS used to only specifies circular arcs. So very simple kinds of curvature. And to really get support for that kind of geometry up and down your whole stack, every level of the stack has to

understand it. So sure, PostGIS understands it. But I don't know that QGIS understands curves natively. So you don't know if you can edit any QGIS experts. Does QGIS do direct curve editing, have a curve object? No, no go. So a lot of tools that have to view curves, stroke them

into linearizations and then draw them on the screen. But you don't have direct editing of them. So you've got to have all the parts. PostGIS has some of the parts. But to do it, practically you need every level of the stack. One of the issues I have trying to get us moved over to the PostgreSQL server as our organization is the DBAs

really don't like the administrative tools, pgAdmin and stuff like that, compared to the ones that are used to working with Microsoft. Any ideas or suggestions on that? Like the actual utilities used to access the database just aren't as pretty as some of the other ones. Yeah, I don't. There are some proprietary GUIs, front ends for

administering Postgres, which make it a little less painful. I think the transition is easier for Oracle DBAs because they're used to being abused. And the SQL server DBAs have just gotten soft. It's always a GUI.

So yeah, I don't know. SQL server is a high bar in terms of providing these really user-friendly affordances. And I don't know any tools that really get to that bar level on the Postgres side. But it is worth poking around some of the proprietary front ends, because they do provide sometimes nicer GUIs for folks.

Will there be more questions? Could you recommend some certification for PostGIS or certification? We have certification courses out of boundless for GeoServer.

We'll eventually have ones for PostGIS. I feel like Enterprise DB does have certification courses for generic Postgres. And those, from the point of view of saying, I'm effective DBA, it's well worth getting those. Because those tend to be really focused on DBA tasks.

The place where PostGIS, PostgreSQL deviates from just plain PostgreSQL in terms of things you might learn is around the SQL and the developer slash analyst roles. Because you could write such different queries in the spatial world than you can write in the plain attribute world.

The actual administration of those databases is exactly the same. So if you learn how to administer Postgres from Enterprise DB, you've learned enough to administer a Postgres PostGIS database as well. Another one? Thank you for coming. Thank you. Thanks, everybody.