What is Reddit's opinion of PostGIS?

From 3.5 billion Reddit comments

Thanks for updating your post. You are right on with your pseudo code. The deal with coordinate systems is that the geom column on parcels2013 and your GPS data must be in the same coordinate system in order for you to use any spatial functions or predicates (INTERSECT, WITHIN, etc...)

The geometry datatype has a SRID property that gives you the code that represents coordinate system of the data. You can query this property using ST_SRID. GPS data is usually in the WGS84 coordinate system (SRID=4326). You must 1) reproject your incoming GPS data to match the coordinate system of your geom column or 2) change your geom column on parcels2013 to a geography datatype and reproject the data to WGS84 (SRID=4326).

There's a PostGIS plugin for loading TIGER data and geocoding from it: http://postgis.refractions.net/docs/Extras.html

Would require some SQL magic/maybe a custom script but could work...There's routines to normalize the address and then geocode: http://postgis.refractions.net/docs/Geocode.html

Edit...Here's a tutorial that talks about it: http://www.stuffzies.com/postgis-geocoder-using-tiger-2010-data

PostGIS is an "extension" to the open source Postgresql relational database. It allows you store and manage geographic features inside of Postgres. Postgesql/Postgis can run on windows or linux. A number of client software can connect to postgis, including Quantum GIS and Arcmap(with ST-links spatial kit extension). You can export out of postgis formats such as KML, SVG or GeoJson. You can also use it as your datastore for web maps in conjunction with Geoserver or you can use PHP/Python/others to create a REST api.

PostGIS's biggest claim to fame is that it has what I believe to be the widest set of spatial operators and functions of any database management system. For instance you can issue a query that selects and then buffers a set of records from one "layer" and use this buffer result to select from another layer.

I almost hesitate to try to steer you toward online resources, because so many are so bad, or so focussed on using ArcGIS (which I think is a pretty terrible tool much of the time).

If you're a "just dive in" kind of person, you might take a look at Ch. 4 of the PostGIS manual for a sampling of GIS questions posed using SQL. Reading that was where I had the aha! moment ("you mean I can SQL this stuff?"). Most of the functions in PostGIS work nearly identically in Spatialite.

For a basic software-neutral description of GIS, the Wikipedia page is okay.

More importantly, if you're a stats student in college, you could consider taking a class or two outside the econ department. If you have an urban planning department, you could take an urban economics class. Urban econ will give you some theoretical basis for economics principles applied to location. Or, if you're looking for a nuts and bolts kind of intro, your geography (or again, the urban planning) department should have intro courses.

Good luck! Sorry I didn't have any amazing online resources to point you to...

That aren't? There's a bunch of Database stuff which needs a bit of work, like index only scans, but it's pretty complete.

The admin tools are a little lacking which might make it a bit trickier to get started.

If you have any geo data I'd say postgreSQL is a must as postgis is awesome.

I'd really suggest storing them on disk. You could optimize the heck out of your Tile class and it's storage, but that would make your system fragile to small changes and will make it even harder to add new functionality.

As a first guess, try using a dbhash and just see how it goes. (http://docs.python.org/library/dbhash.html)

Even better would be a "real" database to store Tile objects, and ideally, use a database that has a geospacial index. For example, you could use MongoDB which has a great feature set for exactly this use case. (see http://www.mongodb.org/display/DOCS/Geospatial+Indexing)

Another alternative would be PostgreSQL with POSTGIS (see http://postgis.refractions.net/) although this is more tailored for "real GIS" not just "big 2d arrays".

I'd write a wrapper TileStore class that pulls in tiles from the DB in "big chunks" of whatever your display size is (say, 32x32) and could manage a pre-fetched set of these "big chunks" surrounding the current point of interest.

That way, your Tile object can be nearly unbounded in size, you can modify and persist it across runs of your program. All you need is a nice fast database with a good 2d index.

An R-Tree Index or a generalisation of an R-Tree (eg: PostGIS GiST Indexes) are suitable for spatial queries.

Apparently mySQL supports R-Tree indexes.