Sunburned Surveyor <[EMAIL PROTECTED]> ha scritto:Peppe,
I would like to try and review some your help documentation for
OpenJUMP functions/menu items.
Do you care if I make these edits directly in the wiki, or should I
make them in a separate document so you can review them?
What do you t
Hello List,
I use a Thread to create several Layers from a Database.
My run-Method calls two other Methods.
First one to create and add the layers.
Second one to create a ColorThemingStyle-Object to add this to the
created Layer.
If the Layer holds a ColorThemingStyle-Object it should be remov
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
On the wiki...
i am not very happy with the idea of transfering all the stuff of the OJ
wiki to the sourceforge wiki. Only the function-help would i consider so
far.
The point is, that the current wiki is quite established and there is
lots of information on the site. It is further impossible f
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
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
btw..
i about internationalization of the wiki: i am not sure if this can be
done either for the oj-wiki (instiki) or the sf-wiki. But I have seen
international ones - such as tikiwi..
stefan
PS: i just played around as well with the sf wiki (i put Sunburneds
structure into the side menu) .. b
Peppe,
I have commited to testing some code for someone after work today, but
I will start directly editing your help docs on the OJ wiki tomorrow
after work.
I think we will keep everything on the OJ wiki for the time being, as
this is what Stefan recommends. (I have no preference for one wiki o
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
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
On 9/8/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
> Hei..
>
> last week i tested and i could extract the html pages of the wiki..
> (after downloading the complete wiki from the backup location)
>
> But it will still need a bit more testing, e.g. if we can just copy the
> html files into an
Hei again,
Sunburned Surveyor schrieb:
> Stefan,
>
> I didn't mean to dig up a bone of contention. Please remember what I
> laid out on the wiki was just a suggestion. I can delete it at any
> time.
not yet.. i played around as well ;)
>
> I brought up the suggestion of using the SourceForge w
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
yupp.. i like it this way much more. :o)
and i never tested gmail - due to google's "acquisitiveness". But just
recently i thought about using it as incomming address for the jpp stuff
stefan
Sunburned Surveyor schrieb:
> On 9/10/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
>> On 9/8/07, Ste
On 9/10/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote:
> On 9/8/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
> > Hei..
> >
> > last week i tested and i could extract the html pages of the wiki..
> > (after downloading the complete wiki from the backup location)
> >
> > But it will still need
Stefan,
I didn't mean to dig up a bone of contention. Please remember what I
laid out on the wiki was just a suggestion. I can delete it at any
time.
I brought up the suggestion of using the SourceForge wiki for two (2) reasons:
[1] Someone suggested the OJ wiki could use a little more structure
Yup. I guess I do sort of talk about whatever I please on the OJ blog, don't I?
I wonder if I can rename the OpenJUMP blog? I'll have to check that
out on the blogger interface.
The Sunburned Surveyor
On 9/10/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
> Hei again,
>
>
> Sunburned Surveyor s
>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
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
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
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
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.
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
> ... 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
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
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
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
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
I wanted to mention something about out spatial reference system
transformation code in a separate thread so that the water does not
become too muddied.
As we talked about before, support for a Z ordinate or elevation
ordinate value in transformation methods is important. As you can see
in the int
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
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
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
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)
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,
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
>
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
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
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
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
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
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
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 :
>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
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
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
>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
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'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
I quickly wrote some CoordinateOperation interfaces based on our
discussion today. They are crude, but I think they may help move our
conversation towards an actual implementation.
Please look them over and then tear them apart. :]
The Sunburned Surveyor
P.S. - You have to change the attached fi
49 matches
Mail list logo
