Replies: 2 comments 3 replies
-
Could fix my problem, at least with the case 2 implemenation - had a small bug with wrong brace position. But is there a more suitable way? |
Beta Was this translation helpful? Give feedback.
-
For case 1 it is hard to tell. Does the geometry in the ContentValues not have the required GeoPackage header? This library does not use JTS so I'm not sure the context of your error. 325 is not a valid geometry type, so I would guess it is probably corrupt geometry bytes. Should be an unsigned integer (4 byte) number like [0-3]0[00-17], where the digit in the thousands indicates if z and/or m values are included. For case 2, you can still use transactions for performance if you wish. See this test.
Again I'm not sure the context of your error as this library does not use GeoTools either. Your code seems to only set geometry column values, not sure if that is intentional or a bug. Is 25832 a hard coded srs id? On the geometry data, you could call setGeometryFromWkb instead of reading the geometry yourself. If you are using the GeoPackage through an external connection or library, make sure you close it first to write the changes. |
Beta Was this translation helpful? Give feedback.
-
Hi,
i have a couple of issues opening the created geopackage file, depending on implementation.
Case 1:
Works fast and smooth. The opening inside a client displays an exception:
Caused by: org.locationtech.jts.io.ParseException: Unknown WKB type 325
Case 2 - using FeatureRow:
Little slower. Client exception:
Any ideas how to solve that problem?
Beta Was this translation helpful? Give feedback.
All reactions