Conversation
1 similar comment
|
FYI. Walked through this with Rich. Had an extra 'compensation' logic for adapting different versions of feature data adapter stored images. Took the adaptive component out by left the version byte in there for future use. Just to recap: The intent of this fix is to retain the axis ordering provided at the time of construction of a feature writable and feature data type. More critically, if the order is provided in long/lat, then that ordering is preserved. |
There was a problem hiding this comment.
do we really want to return an empty string if we can't get a CoordinateSystem?
If we don't want to deal with error propagation back for a nonsense case them maybe use a guava precondition instead?
There was a problem hiding this comment.
Do to the complexity of some of the CRS managed in geotools, I am not sure that we guarantee that the absence of an axis is an erroneous condition. I interpret such cases as undefined or assumed. Although I could test a hand full of CRS. If they all define an axis, then we could go the route of the error. Or we could just accept the undefined case. Then, the question is whether an formal exception is necessary in these cases, a defined return value or , in this case, an innocuous return value.
Thoughts?
There was a problem hiding this comment.
Thinking it over a bit and having a quick discussion with Rich, decided to stick with our default, EPSG:4326 with Axis EAST.
No description provided.