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
