I don't know what version of PostGIS you are using but on >2.0 I first login using psql:
psql -U postgres
Then I create a database:
CREATE DATABASE example_gis;
Then I move into this database:
And then I run the commend:
CREATE EXTENSION postgis;
This creates all the spatial functions, and object types in this database.
I use ogr2ogr to automate ingest of shapefiles into a PostGIS database.
Specifically with regard to the question, use the option:
This will force ogr2ogr to promote POLYGON geometries to MULTIPOLYGON, avoiding the error. A very simple example:
ogr2ogr -f "PostgreSQL" PG:"dbname='<my_db>'" -nlt PROMOTE_TO_MULTI <shapefile>
This appears to be a known issue that won't be fixed: see http://hub.qgis.org/issues/5328
If you need a workaround, try changing your table's geometry column type to a generic 'geometry':
ALTER TABLE my_table ALTER COLUMN geom SET DATA TYPE geometry;
After you've done your import, you can revert back to MultiPolygon:
ALTER TABLE my_table ALTER COLUMN ...
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.
Spit is unmaintained and not recommended anymore. I'd suggest using the processing toolbox and choosing the "Import into PostGIS" algorithm. I've had much more luck using that routine. A few things to note:
The database (connection name) parameter must match what you've named your database connection from the "Add PostGIS layer" dialog.
The schema must ...
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 ...
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 ...
Why use a database?
Because it's not necessarily the case, especially with larger datasets, that you can expect to be able to push the entire thing to the client. If you're talking thousands of points, then sure, but for millions of points you probably don't want each and every one represented in RAM on your end users' client. Not everyone has a super fast ...
It is definitely possible to pull all the layers into one database, although in a multiuser environment, this will be best if most users will only be reading (not editing) the data. The easiest way to quickly convert a large number of shapefiles to a single SpatiaLite database is to use ogr2ogr.
Make sure your shapefiles are in a single folder (e.g. ...
Short and sweet:
Install changeDataSource plugin.
Right-click on the layer in the Layers Panel and select Change vector datasource.
In the dialog box that appears, just hit OK without changing any of the settings.
Basically, you are "changing" the vector datasource to what it already was, but this forces QGIS to reload the layer definition.
Tested in QGIS ...
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.
Contraction Hierarchy is a very fast algorithm:
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:
After the suggestions of user30184, Paul Ramsey and my own experiments. I decided to answer this question.
I failed to mention in this question that I am importing data to a remote server. (although it is described in the blog post I refer to). Operations such as inserts, over the internet are subject to a network latency. Perhaps it is not irrelevant to ...
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 mutli-...
Figured this out! (also asked here)
A record in a spatial table (Shapefile, PostGIS, Spatialite) that has no geometry can have geometry added by adding a 'part' to the feature using the advanced digitizing toolbar. Here's the workflow:
Bring table containing the geometry-missing feature into QGIS
Select the layer from the layers panel and start an edit ...
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 ...
Here is one way to do that:
PouchDB (a framework that uses indexedDB in your browser)
XHR2 (XMLHTTP) to fetch the files, since JQUERY does not yet support binary blob XMLHTTP
KendoUI (an HTML5 web control library)
Running the Demo:
Delete any old DB (Press the Delete Button)
Reload the page
The following snippet works for me:
uri = "file:///C:/testdata/somecsv.csv?delimiter=%s" % (";")
lyr = QgsVectorLayer(uri, 'New CSV','delimitedtext')
For reference, if you wanted to add it with geometry:
uri = "file:///C:/testdata/somecsv.csv?delimiter=%s&crs=epsg:4326&xField=%s&yField=%s" % (";",...
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 easily coerce your data.frame to an sp SpatialPointsDataFrame object.
coordinates(datosmerged) <- ~XCOORD+YCOORD
Assuming that "shape" is a polygon, you can then use the "over" function to identify overlap between the two feature classes. An alternative is "gIntersects" in the "rgeos" package but it a bit overkill for you ...
PostgreSQL has a column limit of between 250 and 1600 "depending on column types", and supports spatial data and queries with the PostGIS extension. So I would be inclined to do two things:
First, where a column represents a category rather than free text, create a separate table with those categories, and replace the column with an integer ID and foreign ...
I recently dealt with the exact same issue with Statistics Canada census profile CSV files containing 2172 columns. You can import your csv into an ESRI File Geodatabase (FGDB) if you have access to ArcGIS. According to ESRI, the FGDB format can handle 65,534 fields in a feature class or table.
In my case, I was able to import my 2172 column wide CSV file ...
I think you should take into account that personal geodatabase is created and accessed through ESRI clients, following proprietary patterns. MsAccess is not a spatial database on its own (it does not provide a spatial data model, so obviously no spatial data loading capabilities, spatial indexing or extended spatial SQL), so ESRI manages spatial information ...
Finally I found the service best shoot my need, Here MAP API. They support mulitiple language and has good zh-hant/zh-hans matching; eventhough, they don't have compelete translate, but well matched, better then Google Map Serivce.
Update Google map is still the best one; during my using the HERE MAP API, I found a lot of cities are missmatched in Chinese ("...
Your best bet is to keep your geometry in shapefiles and keep the data in access. Just make sure there is a common ID in both tables. Both QGIS and Mapinfo support joining shapes to database features (eg accessed via odbc). In Mapinfo, check the function "geocode".
In newer versions of QGIS you can right click the layer and select properties. In the first tab there is a section about layer information with the options for data source encoding. You can select UTF-8 there. Sorry for the German screen shot but since the question was about German characters...