Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent reprojection in addGeoJSONFeatureToGeoPackageWithFeatureDaoAndSrs #196

Open
wants to merge 4 commits into
base: 4.2.x
Choose a base branch
from

Conversation

luca-rath
Copy link

I'm using the @ngageoint/geopackage-geojson-js package, which uses the GeoPackage::addGeoJSONFeatureToGeoPackageWithFeatureDaoAndSrs() method under the hood, to add the features to the geopackage. But the problem is, that I already provide the geojson as LV95, so reprojection is not needed and should not be done.

How could I fix that properly? Would it make sense, to add a flag? Or recognize the SRS of the given feature and only reproject, if the detected SRS is different from the target SRS? I would prefer the latter solution.

@danielbarela
Copy link
Member

As far as I can tell from the spec, all coordinates in GeoJSON are to be specified in WGS84 decimal degrees.

4. Coordinate Reference System

The coordinate reference system for all GeoJSON coordinates is a
geographic coordinate reference system, using the World Geodetic
System 1984 (WGS 84) [WGS84] datum, with longitude and >latitude units
of decimal degrees.

https://datatracker.ietf.org/doc/html/rfc7946#section-4

@luca-rath
Copy link
Author

If you read further:

However, where all
involved parties have a prior arrangement, alternative coordinate
reference systems can be used without risk of data being
misinterpreted.

We are using EPSG:2056 internally and are not going to change that, and all we want is to put those EPSG:2056 coordinates directly into the geopackage instead of double converting them first.

What would you suggest how I could solve my issue?
Thanks for your help

@danielbarela
Copy link
Member

It sounds like you have a more complicated case than is handled by the helper methods. I would suggest that you utilize the API directly and insert your data. Doing that, you can specify your projection for the feature table and simply insert your geometries in that projection. The helper methods are meant to follow the spec without any prior arrangements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants