Matthias, You wrote: "But for save and restore properties in a Task (project) you have simply make a
Map taskProperties = task.getProperties() And then you can put or get your own properties which will be saved/restored automatically. With simple types this runs out of the box. For complex types you have to build a java2xml mapping file corresponding to the java class file." I knew about how OJ used Java2XML, but not about setting simple task properties via the map. I'll take another look at that. Thanks for the suggestion. Matthias wrote: "Second I mean, that we should extend the set SRID stuff. Because most of the EPSG definitions have a "units" parameter. So we can use the EPSG parameters in the future for coordinate transformation and measure computations. The bad way is to have two unit parameters in OJ. Ede please can you tell us your statement, because your are more the coordinate transformation expert than I." I think we are talking about the same thing. It would be nice if OJ didn't assume metric units, but if tools in OJ could take advantage of CRS info associated with a task if they want to. The Sunburned Surveyor On Sat, Feb 19, 2011 at 3:17 AM, Matthias Scholz <m...@jammerhund.de> wrote: > Hi! >> I think Matthias is correct. We should rejigger the tools to work with >> different types of units instead of duplicating tools. >> >> I've looked at adding properties that get saved with the project file >> before (task names I think) and found it wasn't as easy as I wanted. >> It would be nice if we had a way to make writing custom properties to >> the project file a little easier. >> > I don't know, if we talk about the same. But for save and restore > properties in a Task (project) you have simply make a > > Map taskProperties = task.getProperties() > > And then you can put or get your own properties which will be > saved/restored automatically. With simple types this runs out of the > box. For complex types you have to build a java2xml mapping file > corresponding to the java class file. > > Second I mean, that we should extend the set SRID stuff. Because most of > the EPSG definitions have a "units" parameter. So we can use the EPSG > parameters in the future for coordinate transformation and measure > computations. The bad way is to have two unit parameters in OJ. > Ede please can you tell us your statement, because your are more the > coordinate transformation expert than I. > > Matthias >> The Sunburned Surveyor >> >> On Wed, Feb 16, 2011 at 9:49 AM, Matthias Scholz <m...@jammerhund.de> wrote: >> >>> Hi! >>> >>> I prefer a solution with only one tool. To do that we need IMHO a >>> possibility to set/save/restore the unit for the projects data. Than I >>> can extend the new measure tool with the possibility to view the measure >>> result in some different units, such as meter, feet or degree. I can add >>> a JCombobox to select the "output unit" in the options dialog. >>> First we should define on which place in the GUI the user can set up the >>> projects unit. The value can be placed in the persistent blackboard for >>> automatic save and restore. >>> >>> Please correct me, if I'm wrong. >>> >>> @Peppe: >>> Nice idea to store the single points of a measure in a separate layer. >>> But some questions to do that. >>> - should this done with a new menu entry in the measure popup menu? >>> - should this done automatically, controlled by an option? >>> - should the layer name configurable? >>> - and finally, should this be a normal or a system layer? >>> One problem I see. Through the possibility to make multiple mesurements, >>> we can have more than one geometry on the measure layer. When i copy all >>> the points of all geometries on one layer you cannot distinguish this >>> points. A solution can be to save every measure in a seperate layer or >>> with a attribute to distinguish the measurement. >>> >>> Any suggestions are welcome :-) >>> >>> >>> regards >>> >>> Matthias >>> >>>> wouldn't it just be a matter of selecting input and output units first? >>>> that should be done easily. ede >>>> >>>> >>>> >>>> On 14.02.2011 16:54, Larry Becker wrote: >>>> >>>> >>>>> Hi Peppe, >>>>> >>>>> Speaking as someone who often uses Imperial units, thanks for thinking >>>>> of us! I haven't updated to the latest snapshot. Did the "Measure in >>>>> feet" option on the bottom of the tools menu go away? >>>>> >>>>> One of the issues that I have found with any "Measure in feet" tool is >>>>> that it assumes your project units are meters. Of course it doesn't work >>>>> if your units are degrees, but the problem that confuses our users the >>>>> most is when the project units are feet, you can't use the "Measure in >>>>> feet" tool because it will do unnecessary conversion and give the wrong >>>>> answer. >>>>> >>>>> regards, >>>>> >>>>> Larry >>>>> >>>>> >>>>> On Mon, Feb 14, 2011 at 9:17 AM, Giuseppe Aruta <giuseppe_ar...@yahoo.it >>>>> <mailto:giuseppe_ar...@yahoo.it>> wrote: >>>>> >>>>> Hi all, >>>>> I saw that the new measure tools have been substituted the original >>>>> tool into the last OJ Night snapshot. >>>>> I have a couple of proposals: >>>>> >>>>> a) Is it possible to duplicate those 2 tools, but in Feet instead of >>>>> Meters? >>>>> That means that we can have 4 tools instead of 2 (measure distance in >>>>> meters, measure area in meters, measure distance in feet,measure area in >>>>> feet). >>>>> That probably solves many works for people who use Imperial measure >>>>> system. >>>>> >>>>> b) as I can see those tools display also the relative distances >>>>> between points, but those distances are not saved: it would be useful to >>>>> save even that information on an extra layer. >>>>> >>>>> >>>>> regards and thanks >>>>> >>>>> Peppe >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio >>>>> XE: >>>>> Pinpoint memory and threading errors before they happen. >>>>> Find and fix more than 250 security defects in the development cycle. >>>>> Locate bottlenecks in serial and parallel code that limit performance. >>>>> http://p.sf.net/sfu/intel-dev2devfeb >>>>> _______________________________________________ >>>>> Jump-pilot-devel mailing list >>>>> Jump-pilot-devel@lists.sourceforge.net >>>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >>>>> Pinpoint memory and threading errors before they happen. >>>>> Find and fix more than 250 security defects in the development cycle. >>>>> Locate bottlenecks in serial and parallel code that limit performance. >>>>> http://p.sf.net/sfu/intel-dev2devfeb >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Jump-pilot-devel mailing list >>>>> Jump-pilot-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>>> >>>>> >>>> ------------------------------------------------------------------------------ >>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >>>> Pinpoint memory and threading errors before they happen. >>>> Find and fix more than 250 security defects in the development cycle. >>>> Locate bottlenecks in serial and parallel code that limit performance. >>>> http://p.sf.net/sfu/intel-dev2devfeb >>>> _______________________________________________ >>>> Jump-pilot-devel mailing list >>>> Jump-pilot-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>>> >>> ------------------------------------------------------------------------------ >>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >>> Pinpoint memory and threading errors before they happen. >>> Find and fix more than 250 security defects in the development cycle. >>> Locate bottlenecks in serial and parallel code that limit performance. >>> http://p.sf.net/sfu/intel-dev2devfeb >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >>> >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. >> http://p.sf.net/sfu/intel-dev2devfeb >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
