Hei Stefan, hei Andreas, 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 :-)
Michaël 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?) > >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. > >stefan > >PS: you know.. if i would have time.. (maybe in autumn i could also help >with some stuff like testing.) And just for the record: I think, being a >surveyor (my second major was planetary geodesy), I can estimate that it >is realy "heavy" to work on projection and transformation stuff. On the >other hand i must admit that the only projection implementation i have >done was some compulsory assignment at the Uni involving to project >points from german GK coordinates to UTM (which involved also the >transfer from Bessel (or was it Krasovski?) Ellipsoid to ETRS89 (or was >it WGS84 ;) > >Andreas Schmitz schrieb: > > >>Sunburned Surveyor wrote: >> >>Hi, >> >> >> >>>This is great. We need more efforts at collaboration like this. >>> >>> >>I agree. Having a good, free projection library would be desirable. >> >> >> >>>What is the status of the projection code in Deegree? Could it be >>>modified for use in OpenJUMP? (It would probably be easier to use a >>>library from Deegree, since using the port of Proj4 will probably >>>require conversion to another feature model, or at least a geometry >>>conversion of some sort. [Unless the library works with raw file >>>formats.]) >>> >>> >>>Maybe we need to consider using the Deegree projection code in >>>OpenJUMP and if this is sucsessful promoting the library as the "Java" >>>solution for map projection and coordinate transformations. It seems >>>like this would be a logical area for coordination among teams. >>> >>> >>The deegree project decided to implement their own projection library, >>or rather implement it directly in deegree. This will probably happen >>in the next few weeks, since some work has already been done (before >>noting the existence of the proj4 Java port). >> >>For the next major version of deegree, a more modular approach is >>planned, so the projection library is probably going to end up as a >>seperate module that could be used from OJ as library. This is going >>to happen during the next year or two. >> >>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
