I'm not an expert, but simply removing the sidebar dramatically improves readability. Other than that, it looks very feature rich for a 'simple' spatial database extender.
The FAA gave a talk a few years ago about how they moved from Oracle spatial (if I remember correctly) to Postgres/PostGIS for cost reasons, and it turned out to be significantly better all around.
I've honestly never used Oracle spatial stuff directly, and begin a huge fan of PostGIS, I've never felt the need to. However based on talking to people I've worked with, at least a few years ago, Oracle was better when dealing with huge amounts of data.
That being said, PostGIS seems far more popular among practitioners from what I've seen. And it's quite common for the first step in any new GIS project to be to copy the relevant subset of data you're interested in from the Oracle database into a PostGIS database and then use that.
Oracle has some additional features and implements more of the geometry operations correctly but is not materially better than PostGIS for many applications and use cases.
Neither platform offers scalability or high throughput so they are largely differentiated on features.
This is the first time I hear about Oracle spatial stuff being better than PostGIS. Could you give some examples of what those additional operations are?
Also, what is a platform that offers scalability or high throughput?
I always recommend people use PostGIS and used it myself for many years but it was behind Oracle in significant ways even though Oracle is not that great. In recent versions of PostGIS, most users won't notice the differences. Oracle still scales marginally better.
Most importantly, Oracle has always had a better geometry engine that PostGIS, though that gap has closed significantly. It wasn't that long ago that proper geodetic models were not supported at all. And last I knew the current PostGIS does not do pure geodetic for all operations (or so I've heard from the guys who wrote the geodetic geometry engine for my company). Oracle also supports a variety of related data types, operations, and indexes that are useful.
The only platform that currently offers scalability and throughput for geospatial data models is SpaceCurve, of which I am the founder. Among other things, it supports continuous online indexing at a rate of millions of geodetic polygons per second concurrent with queries on petabyte-scale data models. The technology was originally developed for building real-time sensor-fused models of the planet, though it is much more general now.
If I were going to spend a ton of money on spatial solutions, I wouldn't give Oracle a cent. ESRI's SDE is my Spatial Database Extension of choice. It runs on top of Oracle, SQL Server, Postgres and DB2 (You know... if you're an AS/400 person)
Sure, ArcSDE (or whatever it's called these days) is pretty cool, but to be honest I've never seen it deployed in the wild on anything other than Oracle, and often in conjunction with Oracle Spatial. What I've heard is that while the technically support a bunch of databases, they're pretty in bed with Oracle and that is what it works best with.
Around 2007ish they pledged their loyalty to Microsoft and the Oracle users became the redheaded step children. I was at the user conference in 2008 and the few Oracle related demonstrations were poorly attended. Even my organization moved to SQL server around 2011. I left shortly before that.
PostgreSQL has spent a lot of effort on the extension framework ("create extension") to make it easier to support more external modules. If there is a particular area that needs improving, please elaborate.
Making external modules a normal part of the ecosystem, like with ruby (and other popular languages), is the way forward for postgres and has some major advantages.
For instance, given that PostGIS 2.1.0 was just released today, it would make it into 9.4 (as 9.3 is already feature frozen), and 9.4 will be released in about a year. Because it's an extension, you can install it in 9.2 today, or 9.3 when it comes out in a month or so.
Also, just plain modularity, division of responsibilities, allowing for different licensing, and lowering the barrier for contribution are huge wins. The same reasons that ruby has gems.
So, hopefully we can address the concerns with extensions rather than build PostGIS into core.
I would like the geospatial features to be immediately available, and not having to enable them in each individual database. PostGIS setup is well described but I've had a situation where it turned out to be painful.
Anyway now I see the reasons behind the separate module approach and I think it makes sense.
Another added benefit is being able to keep up with the bleeding edge PostGIS and keep some scope of what's changing. If PostGIS was internal to Postgres I'd be a lot less comfortable swapping the configuration so often.
The World Bank http://maps.worldbank.org/ has maps covering multiple economic indicators, coverage is uneven and it's mostly focused on the global south.
http://geocommons.com/ has a largish assortment of geodata but the curation and search functionality is a bit confusing and they require a login.
I needed a rather large test dataset for an aerial imagery basemap, so I went onto USGS's "EarthExplorer" web site [1].
If you need to fetch a lot of data, don't bother trying to download it through the website itself, instead place an order through the "bulk downloader" interface [2]. The order size is limited however, but it was incredibly easy to patch in a simple 'window.setinterval' script through the JS console to make it automatically generate orders from a particular search set.
I waited and waited to find Postgres 9.2 with PostGIS(>=2.0). 9.1 was all that ever materialized. If you're happy with Postgres 9.1, you can do the soft upgrade mentioned in the post. You can also roll your own PostGIS if already are using 9.2. Strangely, Linux is the most annoying platform to install Postgres and PostGIS on. (usage wise, it's just fine) Uninstalling Postgres on Ubuntu can lead to some pretty significant troubles (the /etc/ artifacts remain... don't delete them!!! the distribution packages do NOT contain them)
