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
