Giter VIP home page Giter VIP logo

geopackage-core-java's Introduction

GeoPackage Core Java

GeoPackage Core Libs

The GeoPackage Libraries were developed at the National Geospatial-Intelligence Agency (NGA) in collaboration with BIT Systems. The government has "unlimited rights" and is releasing this software to increase the impact of government investments by providing developers with the opportunity to take things in new directions. The software use, modification, and distribution rights are stipulated within the MIT license.

Pull Requests

If you'd like to contribute to this project, please make a pull request. We'll review the pull request and discuss the changes. All pull request contributions to this project will be released under the MIT license.

Software source code previously released under an open source license and then modified by NGA staff is considered a "joint work" (see 17 USC § 101); it is partially copyrighted, partially public domain, and as a whole is protected by the copyrights of the non-government authors and must be released according to the terms of the original open source license.

About

GeoPackage Core provides core functionality for GeoPackage Library implementations of the Open Geospatial Consortium GeoPackage spec.

It is the core library of the GeoPackage Android SDK and GeoPackage Java library, both which can be found under OGC GeoPackage Implementations by the National Geospatial-Intelligence Agency.

Usage

View the latest Javadoc

GeoPackage Android

The GeoPackage Android SDK is an Android GeoPackage implementation.

GeoPackage Android Map

The GeoPackage Android Map SDK adds Android Map implementations to GeoPackage Android.

GeoPackage MapCache

The GeoPackage MapCache app provides an Android example of using the GeoPackage Android Map SDK.

GeoPackage Java

The GeoPackage Java library is a Java GeoPackage implementation.

Installation

Pull from the Maven Central Repository (JAR, POM, Source, Javadoc)

<dependency>
    <groupId>mil.nga.geopackage</groupId>
    <artifactId>geopackage-core</artifactId>
    <version>6.6.7</version>
</dependency>

Build

Build & Test

Build this repository using Eclipse and/or Maven:

mvn clean install

Remote Dependencies

geopackage-core-java's People

Contributors

bosborn avatar danielbarela avatar fjlopez avatar jyutzler avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

geopackage-core-java's Issues

Table Index Extension invalid foreign key

When using the table index extension, the table is created with an invalid SQLite foreign key to the extensions table. The GeoPackage continues to function but does not pass the SQLite foreign key check.

getCentroid().getZ() returns null

Please fill out as much known and relevant information as possible.

Version Information:

  • GeoPackage Core Java Version: 3.1.0
  • GeoPackage Core Java Source: (e.g. Central Repository, Release, Source Code Build)
  • IDE Name & Version: Eclipse Version: Neon.1a Release (4.6.1)
  • Maven Version: (mvn -version)
  • Java Version: (java -version):1.8
  • Platform & OS: Ubuntu 16.04 LTS
  • Other Relevant Libraries:

Expected Results:

geometry.getCentroid().getZ();

  • What did you expect to happen?
    Return Double

Observed Results:

Return null
always

  • What happened instead?
  • How often does this occur?

Output:

  • Any logs, errors, or output messages?

Steps to Reproduce:

  1. Step One
  2. Step Two
  3. ...

Relevant Code:

// Code to reproduce the problem?
	ResultSet resultSet = SQLUtils.query(connection, sql, null);
	int resultSetCount = SQLUtils.count(connection, sql, null);
	FeatureResultSet featureResultSet = new FeatureResultSet(featureDao.getTable(), resultSet,
			resultSetCount);

	try{
		FeatureRow featureRow = featureResultSet.getRow();
		
		GeoPackageGeometryData geometryData = featureRow.getGeometry();
		Geometry geometry = geometryData.getGeometry();
		geometry.getGeometryType();
		if (geometry.hasZ()) {
			//double z = geometry.getCentroid().getZ().doubleValue();
			//Double corZ = new Double(geometry.getCentroid().getZ()); //getZ() failed cause location null error
			geometry.getCentroid().getZ();
			System.out.println("Output Z");
			System.out.println(geometry.getCentroid().getZ()); // null error
			}
	}catch (Exception e) { 
 			e.printStackTrace();
 			//Component parent;
			//JOptionPane.showMessageDialog(parent,"Open Geopackage Database failed!","",JOptionPane.ERROR_MESSAGE);
 		} 

Test Files:

  • Links to any files needed for testing?

Additional Information:

gpkg_data_columns must have a column "name" with a unique key

Version Information:

  • GeoPackage Core Java Version: 3.3.0 (and develop and master)

Expected:

Observed:

  • The column name of gpkg_data_columns is not unique. The ORM annotation does not enforce uniqueness.

Relevant Code:

/**
* A human-readable identifier (e.g. short name) for the column_name content
*/
@DatabaseField(columnName = COLUMN_NAME)
private String name;

Copy Constructor for Contents needed

The use case is copying data from multiple GeoPackages (each of which have a single bit of contents) to a single GeoPackage. However, my input GeoPackages all have the same user data table name. What I want to be able to do is acquire a Contents object (inputContents = inputContentsDao.getContents(ContentsDataType.TILES).get(0)), copy it (outputContents), and change its name so that I can use it on the output GeoPackage (outputContentsDao.create(outputContents)).

I can do this manually but it would be much better with a reliable/verified copy constructor in place.

Slow Performance

I have been testing geopackage-java by writing 10-50 million trivial geometries. I get relatively poor performance when compared to, say, fastcsv. On a reasonable machine I get ~25 million geometries written an hour.

During my fairly modest investigation, I could not get Connection connection = DriverManager.getConnection("jdbc:sqlite::memory:"); working, including:

SQLiteConfig config = new SQLiteConfig();
// config.setReadOnly(true);   
config.setSharedCache(true);
config.recursiveTriggers(true);
// ... other configuration can be set via SQLiteConfig object
Connection conn = DriverManager.getConnection("jdbc:sqlite::memory:", config.toProperties());
or
Connection conn = DriverManager.getConnection("jdbc:sqlite:file:memdb1?mode=memory&cache=shared");

I also experimented with setAutoCommit(false) but it would appear this would need further work to support.

Any thoughts or suggestions would be great. Thanks!

Version Information:

  • GeoPackage Java Version: mil.nga.geopackage:geopackage:3.1.0
  • GeoPackage Core Java Version: mil.nga.geopackage:geopackage-core:3.1.0
  • Java Version: openjdk 11.0.2 2019-01-15
  • Platform & OS: macOS

Table creation resource loading on Windows

The resource loading for retrieving the SQL files to run for table creation does not work on Windows due to file separator character usage instead of a forward slash. This affects the ability to create new GeoPackages or create new tables within a GeoPackage when on Windows.

Related tables are created and validated using a wrong data type

The method createRelatedTable in RelatedTablesCoreExtension creates a new related table when needed using as data type the name of the relation (i.e. features, media or simple_attributes):

contents.setDataTypeString(relatedTable.getRelationName());

And validates existing related tables data type agains using the name of the relation:
case SIMPLE_ATTRIBUTES:
case MEDIA:
if (!geoPackage.isTableType(relationType.getName(),
relatedTableName)) {
throw new GeoPackageException(
"The related table must be a "
+ relationType.getName()
+ " table. Related Table: "
+ relatedTableName + ", Type: "
+ geoPackage.getTableType(relatedTableName));
}
break;

Contents of new related tables also perform a similar check:
String dataType = contents.getDataTypeString();
if (dataType == null || !dataType.equals(relationName)) {

However, the current draft of the GeoPackage Related Tables Extension states that the GKPG type of the related table shall be attributes for media and simple_attributes relationships.

The current behaviour hinders the usage of GPKG files created with this implementation. For example, GDAL 2 is able to list simple_attributes tables when no attributes tables are present. When any attributes table is present, it ignores simple_attibutes and media tables by default. This behaviour affects QGIS 3 as it uses the default configuration of the underlying GDAL library and then hides simple_attributes tables when they are mixed with attributes tables.

Possible solutions:

  • Extend RelationType to store in a field (e.g. contentDataTypeName) the data content type associated with the relation and use it instead of the relation name for creating and validating content.
  • Make UserRelatedTable subclass of AttributesTables and perform required validations in setContents.

Too rigid date parsing logic

Please fill out as much known and relevant information as possible.

Version Information:

  • GeoPackage Java Version: 3.0.1
  • GeoPackage Core Java Version: 3.0.1
  • GeoPackage Core Java Source: mvn central repo
  • IDE Name & Version: Intellij 2018.2
  • Maven Version: (mvn -version) N/A
  • Java Version: (java -version) 1.8.0_161
  • Platform & OS: MacOS 10.13.6
  • Other Relevant Libraries:
    • Gradle 4.7

Expected Results:

  • What did you expect to happen?
    • I expect more flexible date formatting.
    • At very least I expect the library to continue processing the row after reporting the date format error.

Observed Results:

  • What happened instead?
    exception thrown for invalid date format
  • How often does this occur?
    every time i attempt to read the file

Output:

  • Any logs, errors, or output messages?
    Error importing table drinking_water_supply_management_areas
    mil.nga.geopackage.GeoPackageException: Failed to parse date string: 2016/11/18
    at mil.nga.geopackage.db.DateConverter.dateValue(DateConverter.java:144)
    at mil.nga.geopackage.user.UserCoreResultUtils.getValue(UserCoreResultUtils.java:73)
    at mil.nga.geopackage.user.UserResultSet.getValue(UserResultSet.java:179)
    at mil.nga.geopackage.user.UserResultSet.getValue(UserResultSet.java:72)
    at mil.nga.geopackage.features.user.FeatureResultSet.getValue(FeatureResultSet.java:50)
    at mil.nga.geopackage.features.user.FeatureResultSet.getValue(FeatureResultSet.java:14)
    at mil.nga.geopackage.user.UserResultSet.getRow(UserResultSet.java:104)
    at com.palantir.gaia.upload.gpkg.GpkgFeatureImporter.importTable(GpkgFeatureImporter.java:68)

Steps to Reproduce:

  1. download gpkg file from https://gisdata.mn.gov/dataset/water-drinking-water-supply
  2. note the date column (DWSA_D) in the feature table (drinking_water_supply_management_areas)
  3. run the code below
  4. observe the failure when reaching FeatureResultSet resultSet = dao.queryForAll();

Relevant Code:

geoPackage.getFeatureTables().stream().forEach(tableName -> {
    FeatureDao dao = geoPackage.getFeatureDao(tableName);
    FeatureResultSet resultSet = dao.queryForAll();
    while (resultSet.moveToNext()) {
        FeatureRow row = resultSet.getRow();
        ...
    }
});

Test Files:

  • Links to any files needed for testing?
    ftp://ftp.gisdata.mn.gov/pub/gdrs/data/pub/us_mn_state_health/water_drinking_water_supply/gpkg_water_drinking_water_supply.zip

Additional Information:

  • Any additional configuration, data, or information that might help with the issue?

Create Feature Table With Metadata Methods

Additional create feature table methods that create the geometry columns table if needed, the user feature table, contents row, and insert the geometry columns.

Additional methods should support specifying the name of the id column and/or additional columns. This is currently possible by using the base create feature table method, but requires everything to be created by the caller.

Get the bounding box of a Tile Grid

Provide functionality to retrieve the bounding box of a Tile Grid based upon the total bounding box and the matrix dimensions. This will be used to retrieve the minimum bounding box of existing tiles at a tile matrix zoom level.

Importing large gpkg files is very slow

I have an Android application and I would like to load a very large GeoPackage file that is around 2.0 GB large. I'm using the geopackage-android-map package as my dependency, which internally depends on geopackage-android, which in turn depends on geopackage-core-java. All libraries are running on 3.2.0 version.

When I call GeoPackageManager#importGeoPackage, that 2GB file loads about ~1 minute. I traced it down ultimately inside GeoPackageIOUtils#copyStream, and it appears that we are copying to the buffer at 1K chunks. For reasonably small files this is ok, but if the map spans in the GB, a 1K buffer is too small.

Would it be possible to make this buffer size configurable depending on the size of the file? Or perhaps default the buffer size to 4K (or maybe even 8K) chunks?

Version Information:

  • GeoPackage Core Java Version: 3.2.0
  • GeoPackage Core Java Source: (e.g. Central Repository, Release, Source Code Build)
  • IDE Name & Version:
  • Maven Version: (mvn -version) Apache Maven 3.3.9, Java version: 1.8.0_212, vendor: Oracle Corporation
  • Java Version: (java -version) openjdk version "1.8.0_212", OpenJDK Runtime Environment (build 1.8.0_212-8u212-b03-0ubuntu1.16.04.1-b03)
  • Platform & OS: Android 8 and 9, Samsung Galaxy S8+ device
  • Other Relevant Libraries: geopackage-android-map:3.2.0, geopackage-android:3.2.0

Expected Results:

  • What did you expect to happen?
    Loading a large GeoPackage file (~2GB) should complete at a reasonable amount of time

Observed Results:

  • What happened instead?
    File loads at about ~1 minute. Potentially my Android application can expect to input even larger files, and the hope is those can load reasonably fast as well (relatively speaking)

  • How often does this occur?
    100%

Output:

  • Any logs, errors, or output messages?
    No errors. The file ultimately loads, but it takes a very long time, and it is not a good user experience. Users tend to forget the the file is loading or they get impatient and cancels the download altogether.

Add full Geometry projection transform functionality

Currently you can do projection transformations on single wkb points. It would be useful to have a full Geometry projection transformation which iterates through all parts of the Geometry and transforms it.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.