+1 to make all 3 updates below. Cheers, Chris
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Martin Desruisseaux <[email protected]> Organization: Geomatys Reply-To: "[email protected]" <[email protected]> Date: Friday, June 7, 2013 10:55 AM To: Apache SIS <[email protected]> Subject: Shoudn't GeoHashCoder.decode(String) throws ParseException? >Is there any objection if I had a "throws ParseException" to the >GeoHashCoder.decode(String) method signature? This is a checked exception. > >Additionally, would it be okay to change the return type - currently >double[], to DirectPosition? > >Likewise, what about changing the argument type of encode(double, >double) to encode(DirectPosition)? > >One more issue: the encode(double, double) method currently expect >arguments in (latitude, longitude), which is the correct order from the >traditional geographer perspective. However the programmatic order (in >PostGIS, GDAL, some legacy OGC specifications, etc.) tends to be >(longitude, latitude). This is a kind of "programmatic structure versus >textual representation" issue. We may be better to use a consistent axis >order for API where no CoordinateReferenceSystem is specified (this will >be an other story when we will have a CoordinateReferenceSystem at >hand). What about (longitude, latitude), keeping in mind that this is >only for the API, not for the coordinates to be show to the end users? > > Martin >
