I'm sorry for the confusion I caused with my use of the term "client".
I guess there are really two types of clients:
[1] The application that wants to use our library for performing
transformations. For example: OpenJUMP
[2] The programmer that wants to implement support for a specific
spatial r
By Clients I mean clients of the API (aka other Developers)
Paul
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
__
>I don't see a way around the cost of moving to a geographic "pivot"
>spatial reference system while preserving a single-interface API
>simplicity. That is something I would really love to see. To me the
>wasted CPU cycles are less evil than an API where the client code
>needs to determine a chain
Wait a minute! Maybe we can solve this issue by delegating in the
layer of functionality just under the exposed API.
For example the transformation method might look like this:
transformCoordinate(String argSourceSRS, String argDestinationSRS,
double argXOrdinate, double argYOrdinate, double argZ
Working with so many smart people can really be a pain. :]
Michael wrote: "To take an even more trivial example, imagine you just
have to change
the length unit (meter to feets) or the angle unit (degrees to grads) :
transforming the local data to wgs84 before any operation would be a
very heavy t
Paul Austin a écrit :
>Michael,
>
>I agree with all you said. I guess my statement there was regarding a
>particular type of CoordinateOperation.
>
>
So we are on the same page as Landon said ;-)
>Paul
>
>Michaël Michaud wrote:
>
>
>>Paul Austin a écrit :
>>
>>
>>
>>
>>>Landon,
>>>
>>>A
Michael,
I agree with all you said. I guess my statement there was regarding a
particular type of CoordinateOperation.
Paul
Michaël Michaud wrote:
> Paul Austin a écrit :
>
>
>> Landon,
>>
>> Agreed each CoordinateOperation class should only know how to go in
>> either the direction Geographi
Paul Austin a écrit :
>Landon,
>
>Agreed each CoordinateOperation class should only know how to go in
>either the direction Geographics->ProjectedSystem or
>ProjectedSystem->Geographics. It should not need to know about any other
>systems.
>
>
Coordinate operations are not just Geographics->Proj
Let's think in terms of layers.
The lowest layer is the CoordinateOperation layer which is basically the
Algorithm layer, each algorithm does a single transformation on the
ordinates of a single coordinate.
The highest layer would be a Geometry coordinate transformation layer
which would transfor
Stefan Steiniger a écrit :
>>... but geodesy is a bit more complicated than converting feet to
>>meters, and converting a coordinate to the central wgs84 may be a waste
>>of energy if you just wante to change the projection but stay in your
>>local datum (in this case, your local datum with you
Michael wrote: "JtsTransformFactory.createCoordinateConversion("EPSG:3005",
"EPSG:26910");
to be able to manage other crs databases."
Good point Michael.
Michael wrote: "A simple XYZ shift has to do with spatial coordinates,
as it is one of
the possible operation
to transform geocentric coordinat
Sunburned Surveyor a écrit :
>Michael wrote: "CoordinateOperation should be the main interface."
>
>O.K. - The only thing I find a little confusing about this is that a
>CoordinateOperation might have nothing to do with spatial reference
>systems. I might be simpling translating all coordinates by
just one more final comment:
Paul, you looked on geotools transformation?
stefan
Paul Austin schrieb:
> CoordinateOperations should use the Ellipsoid they are created with (can
> be parameterised), they should not need to know how to do Ellipsoid
> transformations. Ellipsoid transformations woul
Paul Austin a écrit :
>Landon,
>
>My vision for end user code.
>
>JtsTransform transform =
>JtsTransformFactory.createCoordinateConversion(3005, 26910);
>
>
Or
JtsTransformFactory.createCoordinateConversion("EPSG:3005", "EPSG:26910");
to be able to manage other crs databases.
Michael
>Paul
>
Paul Austin schrieb:
> CoordinateOperations should use the Ellipsoid they are created with (can
> be parameterised), they should not need to know how to do Ellipsoid
> transformations. Ellipsoid transformations would only need to be defined
> once in geographics to/from one ellipsoid to another,
Stefan Steiniger a écrit :
>on 2:
>
>i think you both know transformations but just for completeness:
>in: BC Albers x,y + (h) = height over geoid)
>=> inverse-project x,y (+ h) to lat,lon + dh (dh = height over ellipsoid)
>(note: don't know how we will handle geoids)
>=> convert latlon+dh(NAD83)
Stefan,
Yes I did and saw that they have attempted to implements the OGC
interfaces for CoordinateOperations. This unfortunately adds a whole
extra amount of complexity to the implementations. Which although is
useful in some respects is overkill in others.
Paul
Stefan Steiniger wrote:
> just on
On 9/10/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
>
>
> Paul Austin schrieb:
> > CoordinateOperations should use the Ellipsoid they are created with (can
> > be parameterised), they should not need to know how to do Ellipsoid
> > transformations. Ellipsoid transformations would only need to b
Paul wrote: "CoordinateOperations should use the Ellipsoid they are
created with (can be parameterised), they should not need to know how
to do Ellipsoid
transformations. Ellipsoid transformations would only need to be defined
once in geographics to/from one ellipsoid to another, or we could define
CoordinateOperations should use the Ellipsoid they are created with (can
be parameterised), they should not need to know how to do Ellipsoid
transformations. Ellipsoid transformations would only need to be defined
once in geographics to/from one ellipsoid to another, or we could define
a pivot elli
Here is my suggestion for handling ellipsoid issues:
If the implementer of the transformation interface needs to move from
a target spatial reference system that does not use the ellipsoid of
the pivot spatial reference system we provide a helper class called
something like SevenParameterEllipsoid
Landon,
Agreed each CoordinateOperation class should only know how to go in
either the direction Geographics->ProjectedSystem or
ProjectedSystem->Geographics. It should not need to know about any other
systems.
Paul
Sunburned Surveyor wrote:
> Paul wrote: "My vision for end user code.
>
> JtsTra
Paul wrote: "My vision for end user code.
JtsTransform transform =
JtsTransformFactory.createCoordinateConversion(3005, 26910);"
I like it!
My concerns are about how the layer underneath this works. I think a
system where the steps necessary for the transformation are left to
the implementer of
> ... but geodesy is a bit more complicated than converting feet to
> meters, and converting a coordinate to the central wgs84 may be a waste
> of energy if you just wante to change the projection but stay in your
> local datum (in this case, your local datum with your local ellipsoid
> should
On 9/10/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
> on 2:
>
> i think you both know transformations but just for completeness:
> in: BC Albers x,y + (h) = height over geoid)
> => inverse-project x,y (+ h) to lat,lon + dh (dh = height over ellipsoid)
> (note: don't know how we will handle geoi
Michael wrote: "CoordinateOperation should be the main interface."
O.K. - The only thing I find a little confusing about this is that a
CoordinateOperation might have nothing to do with spatial reference
systems. I might be simpling translating all coordinates by a single
XYZ shift, for example.
Landon,
My vision for end user code.
JtsTransform transform =
JtsTransformFactory.createCoordinateConversion(3005, 26910);
Paul
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio
on 2:
i think you both know transformations but just for completeness:
in: BC Albers x,y + (h) = height over geoid)
=> inverse-project x,y (+ h) to lat,lon + dh (dh = height over ellipsoid)
(note: don't know how we will handle geoids)
=> convert latlon+dh(NAD83) to geocentric x,y,z(NAD83)
=> trans
Paul
You wrote: "The key is to make the interfaces as simple as possible so as
to make it easy for people to use and re-use them. I would also not use
abstract base classes, instead I would have concrete classes that can be
parameterized for different implementations of that Projection (e.g.
there
>Thirdly, I think it may be a mistake to create a separate
>CoordinateOperation interface. I believe this will lead us down the
>GeoTools path. A path with many interfaces and classes. What we want
>to do is pretty simple, provide ordinate values in one system and get
>ordinate values back in some
Michael,
I avoided the return type as I don't want to have the extra object
creation, I consider the double[] array parameter to be a temporary
array used just for the one or more operations, rather than the actual
storage of the ordinates. By this I mean when calling an operation you
must expect
Landon,
1. For your point 3, I think defining a simple interface is essential
for what we are trying to do. This will allow us to do things such as
chaining of operations together which I'll cover in response to your
point 4. The key is to make the interfaces as simple as possible so as
to make it
Hi Paul,
That's close to what I can imagine.
Can you explain why you choosed to return void instead of double[]. To
avoid object creation ?
Returning a double[] would have been clearer for me, but may be
returning void is more efficient...
getInverseOperation is not limited to Projection. Datum
Stefan,
I always liked getNorthing() and getEasting over getX and getY myself.
It must be a surveyor thing!
Still, getX and getY work to, as long as this is explained in the
Javadoc or developer documentation.
SS
On 9/10/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> I want to add some com
I want to add some comments to this conversation. I hope that I don't
really confuse things. I think Paul is heading in a great direction
with his interface, and I believe Michael is adding some important
things to the conversation.
First, I agree with Paul on avoiding the JTS Coordinate object at
How about the following interface? The ordinates array has the same
semantics as ordinates in a JTS CoordinateSequence. The values in the
ordinates array are modified in place by the CoordinateOperation.
public interface CoordinateOperation {
void perform(double[] ordinates);
}
For projections
I got used to use North and East (instead x,y which is turned in geodesy
and math and latlon which is purely geographic)
so what about getNorthCoord and getEastCoord?
Usually one speakes also from False Easting (and Northing) for the bias
of the origin point.
i will read the rest of your emai
Hi Paul
>
>1. The reason I chose not to use an array of doubles as a parameter as
>an argument or return type is that what order do you pass in the
>parameters is it lon, lat or lat, lon for geographics.
>
I'm not sure how getX, getY avoid the confusion.
IMHO, coordinate order is relative to the
Hi Micheal,
1. The reason I chose not to use an array of doubles as a parameter as
an argument or return type is that what order do you pass in the
parameters is it lon, lat or lat, lon for geographics. I did consider
having getLat/getLon but that would be even more confusing.
In respect to using
Hi Paul,
I have some questions and remarks about your proposition :
1 - why do you use a setX setY method in the interface instead of
something like
Coordinate transform(Coordinate)
Coordinate inverseTransform(Coordinate)
or
double[] transform(double[])
double[] inverseTransform(double[])
I you
Paul,
This is definitely something I would like to talk to you about some
more.I've come up with a very similar interface, but one that skips
the forward and reverse methods you defined. I think we are both
reaching for the same goal.
I'm camping this weekend, but I'll try to look over your e-mai
41 matches
Mail list logo
