Hi all and The Sunburned Surveyor, Thanks for your reply and welcoming.
I'd be very proud to be, in same way, in the development team. What I can do for now if you agree could be these points: - analyze the Z 3D aspect for OJ - try to hack AdB tool http://www.pcn.minambiente.it/PCN/adbtoolbox.php?lan=it for OJ in my opinion it could give to openjump a great bounce ahead I can translate from italian from everyone interested. - develop some plugins. I'm already done some and work on others but I'm a quite a newbee in java and I'd like to have a sort of tutor to send my "full working " plugin to check for good java code. If you have better scheme for starting to help community I'd follow it thanks and Good New Year everyone!! Luca luca marletta www.beopen.it On Wed, Dec 30, 2009 at 11:01 PM, Sunburned Surveyor <sunburned.surve...@gmail.com> wrote: > Luca, > > These are great issues you are bringing to everyone's attention. Thank > you for providing us with the feedback. > > I like the suggestion about having the z snapping behavior presented > as a set of options in a dialog box. That is something I wish AutoCAD > had too! > > If I implement any of my own editing tools, I will take a look at the > work needed to integrate the Z snap options into OpenJUMP. At least > new plug-ins could then support this behavior. > > The Sunburned Surveyor > > On Mon, Dec 14, 2009 at 2:37 PM, Martin Davis <mbda...@refractions.net> wrote: >> To give a slightly different perspective on this: >> >> I deliberately avoided doing much (any!) interpolation of Z values in >> JTS, because it seems to heavily dependent on exactly what the user's Z >> model is (eg is he working with data which is referenced to a DEM). >> Obviously linear interpolation could be used in some cases, but there >> may be many created points along a segment which might need >> interpolating, and those points might be a long distance from a >> reference point (in which case is the interpolation even useful?) >> Michael lists some other tricky issues as well. >> >> I have thought a bit about this though, and I think that interpolation >> could be done post facto (eg after JTS processing), by matching vertices >> of the output geometry to the input geometry. Where there is a match, >> simply copy the Z value. After this has been done, scan the unassigned >> Z values and try and interpolate them from adjacent vertices. >> >> Essentially this uses the input geometries to define a simple "surface >> model", which then provides the Z value for other points. >> >> Martin >> >> Michaël Michaud wrote: >>> Larry Becker a écrit : >>> >>>> I have added z interpolation to the "Add Vertex" tool for most >>>> "normal" cases. There are some boundary cases that still won't work >>>> without further mods. I have made those modifications to CoordUtil, >>>> but won't commit them until the other developers approve since they >>>> are called by many classes. It is attached. >>>> >>> Hi Larry an Luca, >>> >>> Thanks to Larry for this addition. >>> >>> I think that in the second method average(Collection coordinates), the test >>> if (Double.isNaN(coordinate.z)) >>> should be >>> if (!Double.isNaN(coordinate.z)) >>> >>> About the general request from Luca, I think there are many places where >>> z can be handled in a better way, but one problem is that JTS algo don't >>> interpolate z and what can be done for the Add Vertex Tool may be hard >>> to generalize to other plugins : >>> Examples : >>> Intersection between linestring in a layer : I think z should be >>> interpolated, but the plugin heavily use JTS so that interpolation may >>> not be easy >>> Union : added vertex may have two different interpolated z coming from >>> two different geometries : what to do in this case ? choose one >>> solution, a mean value or NaN ? >>> >>> Snap new vertex to a feature with z : what to do if several points with >>> different z are located where one want to snap ? >>> >>> My 2 cents >>> >>> Michaël >>> >>> >>>> regards, >>>> Larry >>>> >>>> On Fri, Dec 11, 2009 at 9:05 AM, Larry Becker <becker.la...@gmail.com >>>> <mailto:becker.la...@gmail.com>> wrote: >>>> >>>> Hi Luca, >>>> >>>> Thanks for your ideas to improve OJ. >>>> >>>> >>>> A great fix of this behavior could be: >>>> when you add a new vertex the Z will become the linear >>>> interpolation >>>> of the previous and next vertex of polygon or line: >>>> >>>> >>>> It sounds simple enough to modify the "Add Vertex" tool to do this. >>>> >>>> and when you move this vertex it takes the Z of the >>>> destination vertex ... >>>> >>>> >>>> I'm not quite sure about this one. Can you give an example? >>>> >>>> >>>> By the way: is normal that if run OJ from Eclipse (source from >>>> svn) the tools menu is in another place and trunked of a lot >>>> of items? >>>> >>>> >>>> This is definitely not normal. Check your >>>> workbench-properties.xml file. It should normally be empty. It >>>> sounds like you may be getting multiple definitions of the menu >>>> options. We need more information to know for sure. >>>> >>>> regards, >>>> Larry Becker >>>> >>>> >>>> On Fri, Dec 11, 2009 at 8:39 AM, luca marletta >>>> <lucama...@gmail.com <mailto:lucama...@gmail.com>> wrote: >>>> >>>> Follow Stefan guide lines, if I got well, I post a request or >>>> suggestion for a 3D enhancement on existing functions. >>>> >>>> Problem: >>>> working with 3d geometry you often have to add a new vertex >>>> and move >>>> it on an adjacent polygon vertex. >>>> Now when you add a new vertex the Z is undefined and even when you >>>> move this new vertex on an adjacent polygon vertex this is >>>> not able >>>> to change his undefined Z and get the adjacent polygon vertex Z. >>>> >>>> A great fix of this behavior could be: >>>> when you add a new vertex the Z will become the linear >>>> interpolation >>>> of the previous and next vertex of polygon or line: >>>> >>>> a simple mean of Z weighted on 1/distance. >>>> >>>> and when you move this vertex it takes the Z of the >>>> destination vertex >>>> even if this is a behavior in my opinion convenient but >>>> someone could >>>> have different idea. >>>> >>>> I think is quite simple for the maintainer of these class and for >>>> working in 3D is a simple but great enhancement. >>>> >>>> >>>> By the way: is normal that if run OJ from Eclipse (source from >>>> svn) >>>> the tools menu is in another place and trunked of a lot of items? >>>> >>>> >>>> thanks a lot >>>> >>>> luca >>>> >>>> luca marletta >>>> www.beopen.it <http://www.beopen.it> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Return on Information: >>>> Google Enterprise Search pays you back >>>> Get the facts. >>>> http://p.sf.net/sfu/google-dev2dev >>>> _______________________________________________ >>>> 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 >>>> >>>> >>>> >>>> >>>> -- >>>> Larry Becker >>>> Integrated Systems Analysts, Inc. >>>> >>>> >>>> >>>> >>>> -- >>>> Larry Becker >>>> Integrated Systems Analysts, Inc. >>>> ------------------------------------------------------------------------ >>>> >>>> ------------------------------------------------------------------------------ >>>> Return on Information: >>>> Google Enterprise Search pays you back >>>> Get the facts. >>>> http://p.sf.net/sfu/google-dev2dev >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Jump-pilot-devel mailing list >>>> Jump-pilot-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Return on Information: >>> Google Enterprise Search pays you back >>> Get the facts. >>> http://p.sf.net/sfu/google-dev2dev >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >>> >> >> -- >> Martin Davis >> Senior Technical Architect >> Refractions Research, Inc. >> (250) 383-3022 >> >> >> ------------------------------------------------------------------------------ >> Return on Information: >> Google Enterprise Search pays you back >> Get the facts. >> http://p.sf.net/sfu/google-dev2dev >> _______________________________________________ >> 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 the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > 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 the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
