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
