unless you're willing to send Oracle a blank check.
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.
Some links (couldn't find a good primary source): https://twitter.com/magnushagander/status/11107130700 http://scanningpages.wordpress.com/2010/04/11/pg-east-2010-2...
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.
Neither platform offers scalability or high throughput so they are largely differentiated on features.
Also, what is a platform that offers scalability or high throughput?
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.
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.
problems:
- non-compatible licenses
- different release and upgrade cycle
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.
http://www.statsilk.com/maps/download-free-shapefile-maps has a number of pointers to other resources.
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.
1: http://earthexplorer.usgs.gov 2: http://earthexplorer.usgs.gov/bulk/help