Added a fix to convert to default CRS before storing bounding box stats.#308
Added a fix to convert to default CRS before storing bounding box stats.#308chrisbennight merged 1 commit intomasterfrom
Conversation
|
Somebody want to check this out for me? I updated the code to automatically convert entries to our default CRS when recording bounding box stats for feature data. I added a test for this as well. I also made a utility class for the reprojection method that we have been using in a few places. There are also a few random 'code cleanup' and 'formatter' changes. |
|
+1. |
There was a problem hiding this comment.
I know you were re-factoring existing code, but in the case of not being able to transform to EPSG:4326 do we really want to return an feature in the incorrect crs (presumably to be uploaded)? (Caveat: I didn't check upstream of this code to see if there's a CRS check)
I would think it would be better not to upload and throw an error in the log (or maybe even runtime exception, though leaning away from that). Probably last thing we want is to upload inconsistent info.
Or I could be crazy, thoughts?
There was a problem hiding this comment.
The comments explain the original thought process a bit. It seems
reasonable to me though to log an error and cancel the operation when we
can't convert to the default CRS.
Want me to make a ticket or update the existing pull request?
On Apr 3, 2015 7:08 PM, "Chris Bennight" notifications@github.com wrote:
In
geowave-vector/src/main/java/mil/nga/giat/geowave/vector/util/FeatureDataUtils.java
#308 (comment):
crs) && (transform != null)) {// we can use the transform we have already calculated for this// featurefeatureTransform = transform;}else if (crs != null) {// this feature differs from the persisted type in CRS,// calculate the transformtry {featureTransform = CRS.findMathTransform(crs,GeoWaveGTDataStore.DEFAULT_CRS,true);}catch (final FactoryException e) {LOGGER.warn(I know you were re-factoring existing code, but in the case of not being
able to transform to EPSG:4326 do we really want to return an feature in
the incorrect crs (presumably to be uploaded)? (Caveat: I didn't check
upstream of this code to see if there's a CRS check)I would think it would be better not to upload and throw an error in the
log (or maybe even runtime exception, though leaning away from that).
Probably last thing we want is to upload inconsistent info.Or I could be crazy, thoughts?
—
Reply to this email directly or view it on GitHub
https://github.com/ngageoint/geowave/pull/308/files#r27762036.
There was a problem hiding this comment.
Comment only helps if people read it. Whoops.
New ticket is fine - I can make one
#309
Added a fix to convert to default CRS before storing bounding box stats.
Hi