Hot answers tagged database
Boundless' Introduction to PostGIS Boundless (formerly opengeo) has a very very good workshop with a lot of exercises on the PostGIS database. I would start with this one.
PostGIS based on PostgreSQL is a popular database for GIS. I haven't used it much myself, but a pro is that it's open source and that many other GIS uses it so it have an active GIS community.
Some starting points to consider: PostGIS in Action (Second Edition) should be your first resource PostGIS section of 'Introduction to the OpenGeo Suite' Boundless workshops Materials from BostonGIS webpage Also, for general introduction to PostgreSQL I quite enjoyed 'Beginning Databases with PostreSQL' book by Matthew & Stones.
ZIP codes are a habitually abused geography. It's understandable that people want to use them because they are so visible and well-known but they aren't well suited to any use outside the USPS. ZIP codes aren't associated with polygons, they are associated with carrier routes and the USPS doesn't like to share those. Some ZIP codes are points e.g. a ZIP ...
The truth is that most people use a custom variation of the A* algorithm. You will see this across the most of the "big guys"(I can't say who they are in a public forum, but I can tell you that you probably use one of them - guaranteed), where the modification of the heuristics is very dependent on the datasets that they use. You mentioned pgrouting ...
We use Google AppEngine to run spatial/attribute queries and the main issue (from day one) is how to index large sets of arbitrarily sized lines/polygons. Point data isn't too difficult (see geohash, geomodel etc) but sets of randomly clustered small/large polygons was always a problem (and in some cases, still is) I've tried several different versions of ...
Don't check "Save passwords" (and/or "Save username") in the connection - and QGIS will ask for credentials when it needs them.
Not sure if it is newer but pgRouting has a Shooting-Star algorithm: Shooting-Star algorithm is the latest of pgRouting shortest path algorithms. Its speciality is that it routes from link to link, not from vertex to vertex as Dijkstra and A-Star algorithms do. This makes it possible to define relations between links for example, and it ...
Aside from Spatialite, you might also want to consider PostGIS. Think of it as Spatialite's big brother ;-) It's just another data source for QGIS while you can connect to it using the RODBC package in R.
QGIS supports PostGIS - including a dedicated PostGIS Manager plugin for seamless work Spatialite - there is also Spatialite Manager MSSQL 2008 Spatial - also supported by default starting from version 1.8 Oracle Spatial - via OGR but not by default & Oracle Spatial GeoRaster plugin ESRI File/(Personal) Geodatabase - via OGR All database connections ...
The real advantage to spatial databases (PostGIS, spatial extensions to MySQL or anything else) is that you can do spatial operations on spatial data. If you are just storing point coordinates, then you don't really gain much from spatial (just use two numerical columns). If you store combinations of point coordinates (where the customers are), and line ...
I have heard of GeoCouch, which is an implementation of CouchDB for locational based data. And I also think that MongoDB has geospatial indexing capabilities.
take a look at http://www.bostongis.org they have great "An almost idiot guide ..." for PostGIS, Microsoft SQL Server spatial and SpatiaLite. that is really a great start. HTH Nicklas
I suggest you to add Spatialite to your list. It has the benefits of being file based (as a shapefile, or an .mdb database) and supports most of the usual spatial operators and tpyes, that you can find in PostGIS too. Spatialite is based on Sqlite, so you will manage a single file, that you can easily move and share.
For displaying purposes it is always good to use a spatial index. It will improve speed of both rendering and spatial queries. However, if you plan to update large quantities of objects, it might be wise to remove the spatial index during the update. Otherwise the update process will become significantly slower, because with every update the spatial index ...
If all you need is the tables of IDs, text, numbers (no geometries), then your best option is to use ODBC. You can install a MySQL ODBC driver for your system: http://www.mysql.com/downloads/connector/odbc/ download "Windows (x86, 32-bit), MSI Installer". (ArcGIS is still a 32-bit program, even on a 64-bit computer, so you will always require a 32-bit driver ...
I made a test for you: PostgreSQL 9.3 PostGIS 2.1 Windows 7 i7 email@example.com GHz processor GDAL 2.0-dev 64-bit shapefile of 1.14 million polygons, file size 748 MB Ogr2ogr command: ogr2ogr -f PostgreSQL PG:"dbname='databasename' host='addr' port='5432' user='x' password='y'" test.shp --config PG_USE_COPY YES -nlt MULTIPOLYGON Total time:1 minute ...
My way to find PostGIS was http://bostongis.org/?content_name=postgis_tut01#20 there is three parts of the tutorial. I really like it. Then I have to mention: http://postgisonline.org I have tried to build a way of trying spatial SQL queries online. There are a very few tutorials there: http://postgisonline.org/tutorials anyone can write a tutorial and ...
try opening the dbase-file with libreoffice (or openoffice) and try different encodings, if utf-8 doesnot work try iso-8859-1 and look if the chars öäüß are displayed correctly
SQL Server 2008 comes with geospatial capabilities in-built. Even the free Express Edition supports the full geospatial features, as far as I know. Further reading: SQL Server 2008 Spatial Data MSDN: Working with Spatial Data (Database Engine) MSDN: Working with Spatial Indexes (Database Engine) Basic example from Stack Overflow
joining .csv to .shp will be slow. but the best way will be to append the converted .csv file to .dbf and merged based on a unique attribute. You should be able to use model builder to automate most of this. Finally convert the shapefile to file geodatabase.
The bostongis comparison is not a really up-to-date document but it can be a good start, at least to see which aspects is a priority to you, and what you should consider as mandatory or optional to make your choices. The comparison is generic, not related to openlayers. For your OL project, I guess you should also consider the DB availability from your ...
Spatial Databases course from School of Computing, Dublin Institute of Technology. Introduction to PostGIS & Spatial Database Tips and Tricks Workshop from OpenGeo Introduction to Spatial Databases slides from Toni Hernández
Contraction Hierarchy is a very fast algorithm: http://algo2.iti.kit.edu/1087.php This algorithm is RAM friendly while executing a query (to hold a contracted graph some more RAM is necessary as well as massive preprocessing) There are some other algorithms - including the ones that solve public transit routing: ...
Unfortunately, some of those feature are deeply dependent of the piece of software you use. For example, let's take the U-Turns in ArcGIS and PGRouting. In ArcGIS, it is something you can choose as an option, in PGRouting, it is nested in the code. On way street can be processed in two way. The are set up part of the graph with a very high cost ...
Assuming the columns appear in time order, the first row (for example) indicates that total construction through each period went 0, 0+45 = 45, 45+135 = 180, 180+405 = 585, 585+1010 = 1595, ..., 2230+0 = 2230. Construction was halfway through at 2230/2 = 1115. This occurred during period 4, because at the end of period 3 the total was 585, at the end of ...
Not sure if you will be able to work with MS Access in QGIS (plus I haven't heard about any respectable GIS-project that would use MS databases); MSSQL - is supported (but never tried it myself and never will ;-) ). Consider possibility to use Spatialite (spatial extension of SQLite). It will be quite suitable to operate Spatialite DB in QGIS and you can ...
You should certainly consider the hugely popular, well established, widely supported (and free) PostGIS. It will do every thing that MySQL can do and handle spatial locations as first class objects. Thus you can carry out selections based on points with in a bounding box (or other polygon) without having to write out all the comparisons etc. Once you start ...
You can achieve this by preparing all those layers in one (or more) project files. Share these projects on the network and you can load them using Layer - Embed Layers and Groups. If you want to change anything in these layers, open the original project file and changes will appear in all projects that contain embedded layers.
In Addtion to saving defined layer styles within project files on the network, you can create a single Spatialite enabled database.sqlite, if your workflow isn't too busy. For myself, I've replicated a fgdb by importing a hundred shapefiles and a couple hundred datatables, with great performance. Spatialite won't allow for PostGIS or FileGDB style ...
Only top voted, non community-wiki answers of a minimum length are eligible