Matthias, You are a fresh breath of reasonableness and your criticism of my proposed interface was very constructive. Thank you. Please see my comments below.
Matthias wrote: "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." Your argument makes sense to me now. I agree that CRS discovery could be important for a lot of GIS users. However, I think we need to separate the following programming challenges: - Detecting the CRS for a data set without any metadata.and/or user input. - Determining the CRS for a data set with metadata and/or user input. - Transforming feature geometries in a data set from one CRS to another. Althought the first two problems are important, my proposed interface only addressed the third problem. I'm not even sure how I would start to tackle the first two problems. Maybe an interface that allowed the user for a list of viable CRSs based on an envelope. I think Martin mentioned that before, although I don't know if his module contains code that would allow a user to do this. Matthias wrote: "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);" OK. In that case I would scrap the setSourceCRSByWKT and the setDestinationCRSByWKT methods altogether. Why pollute the interface? Have a utility class that allows for the easy creation of a CRS using a WKT definition. I'd be most interested in a utility class that got me from an EPSG code to a CoordinateReferenceSystem object anyways, although Paul may have a reason he likes WKT. Matthias wrote: "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?" I like this approach as well. I most cases I think copying is better than modifying the original. Matthias wrote: "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'm open to making the interface stateless, but I don't understand how we will do that. How else will we specify the source and destination CRS? Unless we pass it explicitly to the transform methods everytime we make a call to transform a coordinate. In this case we would delegate the responsibility of parsing and storing the CRS definition to the client code. Do you like that approach better? Landon On Tue, Oct 14, 2008 at 11:54 AM, Matthias Basler <[EMAIL PROTECTED]> wrote: > (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 > ------------------------------------------------------------------------- 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
