... I should have said Geopackage is „not optimal“ in regards to space
efficiency. It‘s still not bad at all when compared to other formats.
Am 07.08.2018 um 23:35 schrieb Benjamin Stadin
mailto:benjamin.sta...@heidelberg-mobil.com>>:
Geopackage is not very space efficient, due to the required
Geopackage is not very space efficient, due to the required compatibility with
the spec and the „ST*“ methods matching their postgres counterparts. Check the
header which is carried over for each geometry:
https://github.com/opengeospatial/geopackage/blob/master/spec/2a_features.adoc
For an exam
Yeah it's not the geopackage format but that the polygons are just huge,
sorry about that. There is ~1000 polygons but each one is a ton of
vertices (~100k), so zoomed out the redraw takes a little while (seconds).
This is true with fileGBD too, which feels slower than the gpkg FWIW. In
practice
Patrick Young wrote
> We also tried a GeoPackage, but it seemed a little slow to read in QGIS.
Hi,
Could you give some more details about your GeoPackage and what you mean
with "little slow"? I have pretty good experiences about using GeoPackage as
data source for MapServer. I also just tried ho
> I still prefer and use that to deliver, over the heavier GPK format.
Sizes of GeoPackage and Spatialite DBs should be very similar in most cases.
They differ only by the geometry encoding, which in both cases is more or less
a header + WKB or a variant of WKB. Spatialite DBs can be significant
My next choice for customers (in cases of a hard file requirement) is
always Spatialite (sqlite3 + libspatialite wrapped into a single file).
I still prefer and use that to deliver, over the heavier GPK format.
(again, everyone has their own preferences, I'm just sharing my 18+
years of MapServ
Ah right of course! I should have said that we deliver these things to
customers, so a file format is needed. We've have had good luck serving
simplified versions of these things out of zipped shapefiles from S3 via
mapserver so the thought was maybe the same trick would work with the right
forma
Hi Patrick,
In terms of speed and MapServer, considering you have large vector data
and require good indexing, I always use and recommend PostGIS.
(of course if you asked this on the MapServer-users list you would get a
whole lot of different opinions)
But that is my initial recommendation,
Hi all,
I've been trying to figure out a good format to store some very large
vector data in. Basically, its a bunch of really dense polygons describing
the cutlines that compose a mosaic. We've had reasonable success using
zipped shapefiles, but on the larger guys we're exceeding the 2GB file
s
