I work with geodesy concepts and map projections a little in my work,
and I had a suggestion I would throw out there. Please for give me if
my ignorance shines through here.
If we are thinking of a simple library that only transforms
coordinates and not higher-level objects I think the implementation
could be kept very simple. (I really like this idea of only
transforming coordinates, since it means multiple projects could
benefit.)
Why not define a couple of simple transformation interfaces like the following:
public interface horizontalTransformer
{
public double convertToLatitudeInDecimalDegrees(double ordinate);
public double convertToLongitudeInDecimalDegrees(double ordinate);
i
public double convertLatitudeInDecimalDegreesToOrdinate(double latitude);
public double convertLongitudeInDecimalDegreesToOrdinate(double longitude);
}
public interface verticalTransformer
{
public abstract double convertOrthometricHeightToOrdinate(double
orthoHeight);
public abstract double convertEllipsoidHeightToOrdinate(double
ellipsoidHeight);
public abstract double convertOrdinateToOrthometricHeight(double ordinate);
public abstract double convertOrdinateToEllipsoidHeight(double ordinate);
}
The idea here is that you leave the details of the conversion math to
those implementing the interfaces. These are likely the individuals
the most qualified to get it correct. (For example, I'd be great at
writing the code for California State Plane Coordinates, but I'd
really stink at doing the same thing for a projection used
commonly in Europe.)
You are also using latitude, longitude, and ellipsoid or orthometric
height as a common "transport" medium or format for position. That
means that as an implementer of the interfaces I don't need to worry
about how to support 6000 map projections, I only need to worry about
how to get from my projection to lat/long/height and back out again.
If a programmer needed supporting information, like ellipsoid or geoid
parameters,
these could be encoded as utility classes.
This is just a thought.
The Sunburned Surveyor
> Hei Andreas,
>
> as Michael pointed out: we will try to support you.
> And having a 3d person working on it - should be ok. At least he is firm
> with all the 3d coordsys stuff. Working with ellipsoids is still a bit
> different but learnable. I am glad that Michael has also some
> experiences on that too..
>
> stefan
>
>
> Andreas Schmitz schrieb:
> > Michaël Michaud wrote:
> >
> > Hi,
> >
> >> Making a new projection library is a very exciting project.
> >> As there are at least two other projects (javaproj and geotools) I'd
> >> like to make sure I undersand what would be the specific purpose of a
> >> new library.
> >> Javaproj and geotools have very different approaches (opposite ?), the
> >> first being very procedural (mainly math functions), and the second very
> >> object oriented (with a design based on OGC UML diagrams and GeoAPI
> >> interfaces).
> >> What would be the specific target of a third library ?
> >> I must admit that I'd like to see a complete lightweight library
> >> (including datum transfo, coordinate system transfo, and the capability
> >> to add complex transformations). I can't say if there is a better
> >> solution than geoapi/geotools. A few years ago, I felt geotools api was
> >> very complex and enable to solve the problems I had with some special
> >> transformations (french grid-based datum transformation), and I tried to
> >> design a new small library you still can find here :
> >> http://michael.michaud.free.fr/geodesie/JTransfoCoord.html
> >> I'm not completely satisfied with it and today, I would hesitate between
> >> a shift to geotools or a rewrite of this library.
> >> But in any case, I would be pleased to participate and to help with any
> >> project with the aim to incorporate projection stuff into OpenJUMP :-)
> >
> > That's good to hear :)
> >
> > When the time is ripe and our library usable, I'd also help
> > integrating it, of course.
> >
> > As to the other libraries (geotools etc), I'm not sure where the
> > deegree projection library fits in. I guess that depends a lot on how
> > much time can be put into this. From my (admittedly VERY narrow) point
> > of view it shouldn't be too difficult to implement a database based
> > approach that can transform between different types of coordinate
> > systems (like proj4) in Java, at least for the common types. But then
> > I read Stefan's comment ;-)
> >
> >> Stefan Steiniger a écrit :
> >>
> >>> Hei Andreas,
> >>>
> >>> thats good to hear.
> >>> I hope you are looking on geotools projection code as well. As far as i
> >>> checked out the guy that is responsible for it has the appropriate
> >>> background (at least i think so). and geotools realized already lots of
> >>> projections ( i guess EPSG completely). But lots of stuff needs to be
> >>> replaced.
> >>> Just a question: do you have a person with proper math-geodesy
> >>> background on projection stuff? (or a contact to Bonn University on
> >>> that: i.e. someone of the team of Prof. Karl-Heinz Ilk?)
> >
> > It's a computer scientist working on it. He's more into 3D, but he's
> > also quite firm in math, I believe ;-)
> >
> >>> I ask, because projections are a realy nasty thing. It is very important
> >>> to have appropriate testing data (e.g. to check the conversions to
> >>> WGS84). (btw: I did some software evaluation on Cadcorp SIS for Finnish
> >>> projection - which is to complicate for them, Swiss projection (also
> >>> some special formulas) and German GK/UTM projections).
> >>> It is somehow "satisfying" to hear that you plan to work on the
> >>> projection support implementation for 1-2 years (not just a month). I
> >>> think the "design" itself is also quite tricky, because later on the
> >>> user must be able to define its own coordinate system (beside the EPSG
> >>> ones). So it is good to look how ArcGIS, Cadcorp SiS, MapInfo, and so on
> >>> have realized the user interfaces and customization.
> >
> > Yes, that's definitely true. I think my company tried a lot of
> > different approaches to the problem during the past years, and none
> > were satisfying (else we wouldn't try a new one...).
> >
> > Best regards, Andreas
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
