---------- Forwarded message ----------
From: Sunburned Surveyor <[EMAIL PROTECTED]>
Date: Mon, Oct 13, 2008 at 5:05 PM
Subject: Re: [Geotools-devel] Geotools-devel Digest, Vol 29, Issue 14
To: Matthias Basler <[EMAIL PROTECTED]>
Let me briefly respond to some of your comments Matthias:
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". Are we talking
about academic or scientific applications? I would argue that most
people using an application like UDig or OpenJUMP (and your typical
ESRI user) are not geodesists. They want to translate their data from
one well-known and published coordinate system to another. In my day
job I work with the same four (4) or (5) map projects all the time.
I have an appreciation for geodesy, but I would wager that %95 of the
FOSS GIS users don't need to define custom map projections or work
with anything that doesn't already have an EPSG code.
Matthias wrote: "The interface should imho live in GeoTools, not
GeoAPI, because it has nothing to do with any official standard."
I agree. We are really talking about high-level implementation here. I
don't think this should go in GeoAPI.
Matthias wrote: "Using WKT for this convenience class sounds like a
bad idea to me. Besides the problems pointed out by Martin simply the
idea of having to parse a WKT (or whatever) String to create a CRS
object just in order to transform ONE single coordinate at a time
sounds so awfully inefficient to me that I cannot seriously consider
it."
What would you suggest as a good alternative? (I"m open to other ideas.)
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.
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. (I know the math is complex, and
that's one reason why the code is complex.) I really think the CRS
code in GeoTools would get more use if it was easier to plug-in to
other projects. Leave the complex code for those with special use
cases, but make hide the complexity for the other 95% of us that just
want to translate a shapefile from WGS84 to California State Plane
Zone 3. :]
Landon
On Mon, Oct 13, 2008 at 10:30 AM, Matthias Basler
<[EMAIL PROTECTED]> wrote:
>> Sunburned Surveyor a ?crit :
>> > I agree with the need for simplicity. In my example, you only dealt
>> > with one object, the object implementing the transformation interface.
>> > In the example from GeoAPI that Martin posted, you have to deal with
>> > at least four (4) objects:
>> >
>> > [1] CoordinateReferenceSystem
>> > [2] CRSFactory
>> > [3] MathTransform
>> > [4] CoordinateOperationFactory
>> >
>> > I think all of this could take place behind the scenes, in the class
>> > implementing the interface.
>>
>> Yes it could take place behind the scene by your proposal, which would be
>> a convenience class as stated in previous emails.
>> [...]
>> But there is cases were the user will need to work with those above GeoAPI
>> objects rather than the convenience class. For example when wanting an
>> estimation of transformation accuracy, or when wanting to know in which
>> geographic area a CRS or a transform is valid.
>
> I completely agree with Martin on this topic:
> 1. The GeoAPI interfaces do their job and allow for a wide range of
> coordinate transformations, CRS creation and and CRS metadata retrieval, as
> used f.e. in my CRS selection widgets. Moreover it is an ISO standard.
> Therefore the GeoAPI interfaces cannot and should not seriously be hidden
> behind a facade for most serious GIS applications.
>
> 2. For those users that think they really only need a simple coordinate
> transformation a static utility class would do the job of hiding the
> complexity without touching GeoAPI interfaces. This utilitiy class could then
> implement the simple interface proposed earlier. I doubt the simple
> transformation method proposed by Landon will satisfy all but the most simple
> use cases, but it is worth a try.
> The interface should imho live in GeoTools, not GeoAPI, because it has
> nothing to do with any official standard.
>
> 3. Using WKT for this convenience class sounds like a bad idea to me. Besides
> the problems pointed out by Martin simply the idea of having to parse a WKT
> (or whatever) String to create a CRS object just in order to transform ONE
> single coordinate at a time sounds so awfully inefficient to me that I cannot
> seriously consider it.
>
>
> The shortest useful code 'd come up with is
> CRSFactory crsFactory = ...
> CoordinateReferenceSystem sourceCRS = crsFactory.createFromWKT("...");
> CoordinateReferenceSystem targetCRS = crsFactory.createFromWKT("...");
> double[] dstCoords = CRSUtility.transform(srcCoords, sourceCRS, targetCRS)
>
> and for multiple coordinates:
> double[][] dstCoords = CRSUtility.transform(srcCoords[], sourceCRS, targetCRS)
>
> This keeps the flexibility of creating the CRS objects in any way you like
> and reuse them, but it saves just one line of code compared to the interfaces
> we already have, so is it really worth this?
> --
> 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
