On Tue, 4 Mar 2014 23:13:51 +1100, Nik Sands wrote:
The conversion process is a little slow for large data sets
Hi Nik,
SQLite is a transactional DBMS and consequently your
approach to transaction handling has a very strong
impact on write performances.
just as a quick and dirty rule-of-the-
Thanks to everybody who helped me towards getting this working - it is now
working correctly. The conversion process is a little slow for large data
sets, but the results are excellent, and the Spatialite databases are MUCH
faster for spatial filtered lookups than the Shapefiles I had been usin
Thanks for this information.
I'd like to replicate that ogr2ogr PROMOTE_TO_MULTI functionality in my code,
but I'm having trouble figuring out how to do it. I guess I can take a look at
the ogr2ogr code.
(I could also just include the entire ogr2ogr tool bundled into my app and call
it from t
Selon Nik Sands :
> You are correct - I did misunderstand. Thanks for further explaining the
> multiple geometries to me. :-)
>
> So it looks like the best option for me is to make a copy of each source
> layer which may contain both single and multi variants (eg, point and
> multipoint features
You are correct - I did misunderstand. Thanks for further explaining the
multiple geometries to me. :-)
So it looks like the best option for me is to make a copy of each source layer
which may contain both single and multi variants (eg, point and multipoint
features) and make the new SQLite l
Hi all,
just yo better clarify some relevant details:
a Shapefile can legitimately contain one the following shapes:
Point, PolyLine, Polygon and MultiPoint; and there are further
shape-codes intended to support extended XYZ or XYM dimensions,
such as PointZ and PolyLineM
please note: according
Nik Sands nixanz.com> writes:
>
> Thanks Chaitanya,
> It's finally dawned on me that this is what the following is about in the
OGR SQLite format web page:
>
>
> Tables with multiple geometries
> Starting with OGR 1.10, tables that have multiple geometry columns
registered in geometry_columns
Thanks Chaitanya,
It's finally dawned on me that this is what the following is about in the OGR
SQLite format web page:
Tables with multiple geometries
Starting with OGR 1.10, tables that have multiple geometry columns registered
in geometry_columns can be used by OGR. For such tables, there a
Nik,
One option I frequently use when uploading shapefiles to PostGIS is to set
the -nlt option in ogr2ogr. Setting it as
multipolygon/multilinestring/multipoint for a shapefile defined as
polygon/linestring/point usually overcomes the problem.
Check if Spatialite allows adding single geometries
So now, instead of the 'OGR_DS_CopyLayer', I'm using the code below to run SQL
queries to split each layer from the source data set into multiple layers in
the destination (Spatialite) dataset based on the geometry types. (The
addNewLayerNames: method will not add empty layers).
It appears to
Thanks for this tip. I think you're on the right track with mixing single line
strings with multi line strings and single polygons with multi polygons.
(I don't think the number of features is causing any problems as it happens for
some very small groups of features also.)
It appears as though
Nik Sands nixanz.com> writes:
>
> Hi all,
>
> I'm planning to switch from using a standard file format of Shapefiles to
Spatialite for internal storage
> of spatial data.
>
> When importing from other formats, the app attempts to convert these to
SQLite (Spatialite) using
> 'OGR_DS_CopyLayer'
Hi all,
I'm planning to switch from using a standard file format of Shapefiles to
Spatialite for internal storage of spatial data.
When importing from other formats, the app attempts to convert these to SQLite
(Spatialite) using 'OGR_DS_CopyLayer' to copy each layer from the source data
set to
13 matches
Mail list logo
