(Sorry for the wrong subject of my last mail.) Landon wrote: > Matthias wrote: "Therefore the GeoAPI interfaces cannot and should not > seriously be hidden behind a facade for most serious GIS > applications." > > I think we need to define "serious GIS applications".
Agreed, this naming was not optimal. My reasoning was: I most GIS applications that care about CRS the user has to choose a CRS for his/her map. In order to do so the application needs discovery mechanisms and mechanisms so the application can query metadata about the CRS in order to show it to the user so he/she can make a sensible decision for a CRS valid in this area. I didn't have geodesists in mind. On the contrary, those people NOT deeply involved in geodesy need the most help for creating maps with sensible CRS decisions, imho. They want to know if the shapefile they got from somewhere is in the correct coordinate system or if they have to reproject it at all and so on. > I don't think you'd have to parse the WKT definition everytime you > wanted a single coordinate. You could set the source and destination > CRS, have it parsed by the transformer, and then reuse the parsed > instance until new CRSs were set. Correct, I have overlooked this possibility for reuse in your proposed interface. My point is that the interface should not restrict CRS creation to creation from WKT, especially since WKT is obviously the worst case in terms of axis ordering. So going forward, how about: public abstract void setSourceCRS(CoordinateReferenceSystem crs); public abstract void setDestinationCRS(CoordinateReferenceSystem crs); public abstract void setSourceCRSByWKT(String wkt); public abstract void setDestinationCRSByWKT(String wkt); public abstract double[] transformCoordinate(double[] coordinate); public abstract double[][] transformCoordinate(double[][] coordinate); public abstract List<double[]> transformCoordinate(List<double[]> coordinate); Some could argue the last method is redundant to the one above, but since we are talking about a convenicene interface anyway, not having to convert lists to arrays and back means convenience to me. One other thing to decide on is whether the transform method should modify the input object (potentially saving memory) or creating a new array/list of new arrays leaving the input untouched. Often I see code like this ... public abstract void transformCoordinate(double[] srcCoord, double[] dstCoord); ... so you can choose to set the original array or a new one as destination. The more I think about it the more I like this approach. Opinions on this? BTW, the above concept would mean that the class implementing the interface is stateful (it saves the source and destination CRS). Intuitively I'd use a stateless abstract class and save the source and destination CRS somewhere else. But this is more a matter of liking, or so it seems to me. > I know that Martin did a good job with his CRS transformation module. > But let me be honest from the perspective of a consumer of the module: > The code is pretty stinking complex. It is. Especially some CRS metadata retrieval methods and all the hints around look a bit over engineered to me (although others will correctly claim this complexity is needed). -- Matthias Basler [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
