Tag Info

New answers tagged

2

From the ogr2ogr docs, use the -nln name option to assign an alternate name to the new layer.


0

I wanted to use comment but i can´t post screenshots there I so I hope its ok to do it as an answer (?) Thanks for still wanting to help. I´m still a bit confused. Why should the newly created "Test_table2" have a geometry column after I create it with above code. The symbol is just the normal table symbol and the field list looks like this If I then try ...


2

Standard OSM tiles are in Spherical Mercator (SRID=3857) so it will probably be easiest to build your grid using the same projection. If you use SM, you might store the data at the highest zoom level OSM supports, or at the highest level zoom level you'll permit users to zoom into. If coverage is sparse, use a data structure along the lines of XIndex, ...


0

If your first "test_table2" already had a geometry column, then the AddGeometryColumn() function will fail. (You will see a '0' in the resulting output). To do this correctly try the RecoverGeometryColumn() function instead. It takes exactly the same parameters as AddGeometryColumn(). Alternately, you can check the meta table called "geometry_columns" and ...


0

The information in the other post helped and solved like "half" of my problem. A very easy solution is to make a new table with a pkuid field an get all records from the old table into the new one. I did that in Database Manager using the modified code provided by Freeman: ; Creating new table CREATE TABLE test_table2 ( PKUID INTEGER PRIMARY KEY ...


5

And, after a bit more reading the ogr2ogr help I found the answer more easily than I expected. ogr2ogr -f "PostgreSQL" PG:"dbname=db" spatialitedb -sql "SELECT * FROM table" -dialect spatialite -nln new_table EDIT: As suggested by user30184 in the comments a cleaner, simpler method is: ogr2ogr -f "PostgreSQL" PG:"dbname=db" spatialitedb ...


1

It seems you miss the ST_relate function like in PostGIS. Search "relate" word in the reference functions for version 4.2. The signature will look like below : ST_Relate( geom1 Geometry , geom2 Geometry , patternMatrix String ) : Integer patternMatrix is the DE-9IM pattern. PS: If your spatialite version is old, ST_relate may be named relate


2

Yes it can be done with QGis. Using the QSpatiaLite Plugin "Manage your SpatiaLite databases within QGis" After installing the plugin you can run it. You will receive a series of messages/errors stating that you do not have a spatialite db. it will step you through getting one installed (choose a location for the file) and finally converting it to ...


2

There is no direct equivalent, however you should be able to do something similar with a combination of RotateCoords() which rotates the geometry (in degrees, rather than radians), ShiftCoords() and ScaleCoords(). Here is an example, simplified from the test suite: SELECT AsText(RotateCoords(geom, 0)), AsText(RotateCoords(geom, 90.0)), ...


0

As @BradHards suggested I'm posting my solution: I installed PostGis, Imported the data, and executed the following query: create merged as delomrade_code, st_union(geometry) from grunnkrets group by delomrade_code results were much better with my data. first it executed in minutes. and the result set has only 6 MULTIPOLYGONS out of 1546 as oppose to ...


0

If you converted the data to KML, and didn't change the coordinate reference system when you went from KML to SHP, then the units are almost certainly in degrees. Let me say that again - your distance measure is now degrees. It is not metres, miles or kilometres. Degrees probably isn't what you wanted for a buffer. So you may want to project (using the ...


1

Solved! I was wrong when using the optional parameters syntax. SO, creating the spatialite database using the Spatialite format for the geometry column was my problem as it was defaulted to WKB format that was not appropriate for what I wanted to do. QgsVectorFileWriter.writeAsVectorFormat(layer, layer.name() + ".sqlite", ...


0

You can surely reduce the amount of data in the sourcefile before storing it in the spatialite database. OSMfilter or osmosis are powerful tools to filter the data. It depends on what you are after. If you only need streets, you can drop buildings and housenumbers. In some parts of the world these take a growing part of the database.


1

It is not the size of the database that makes it slow, it is that you select too much to render. Simplification can be a part of the solution but it will not be enough for making you happy. You can do lot of things once the data are in Spatialite. As you suggested, simplify "update lines set geometry=ST_Simplify(geometry,0.01);" Do the same but instead of ...


1

perhaps not as much an answer as a workaround? not sure what is going on with GetNextFeature in conjunction with SetFeature - but it would not iterate as expected. (a bug?) the below workaround seems to do the trick - by first getting a list of all feature FID's - then using GetFeature() in a new loop. def updatePt(): print 'updating...' ...



Top 50 recent answers are included