Message-ID: <1623512831.13802.1414288843826.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_13801_142159261.1414288843826" ------=_Part_13801_142159261.1414288843826 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page is supposed to hold ideas and goals for 3D rendering in GeoToo= ls/GeoWidgets.=20
This is a call for opinions and ideas. So please answer.=20
Anything geometry-related I could find.=20
Any more known geometric-related libraries?=20
It would be favourable to have 1D-3D objects stored in an intuitive, geo= graphy-aware geometry API. The former means f.e. that objects can be constr= ucted the way a geographer would expect it. A sphere would f.e. be defined = by a center point [x,y,z,crs] and a radius [double,Unit?]. This means that = 3D objects are stored with 3D coordinates and a 3D CRS that defines their e= xact location on earth.=20
The same API should also contain 1D and 2D objects: Coordinates(=3DPoint= s), lines, arcs, flat polygons and the like. 2D and 3D objects should work = together seamlessly: If no elevation data is available (as in shapefiles) &= quot;flat" 2D objects (elevation=3D0) could be created. The same objec= ts could be derived from a 2D projection of 3D objects onto the earth surfa= ce. Also solids as f.e. boxes could deliver their faces in form of 2D objec= ts (this time usually with elevation!=3D 0).=20
In the case of "flat" objects (with elevation=3D0) JTS operati= ons could be used, possibly with the need to convert back and forth since t= he 2D objects would probably not be subclasses of JTS objects, which are &q= uot;flat" 2D only.=20
Anyway, at a later stage 3D geographic functions would need to be added,= such as 3D buffer, distance, intersections, splitting 3D objects a.s.o.=20
Is there any API that fulfils all above idea or comes clos= e to it? Something like JTS but in 3D maybe?=20
Above explained geometries should be rendered either on a 2D or 3D canva= s. For this, Java2D resp. Java3D are the implementations of choice in the A= WT-compatible Java world. They are both working.=20
Are there working alternatives to Java3D for 3D rendering?==20
One of the goals is that the same geometries can be used in either conte=
xt. In either case - 2D or 3D rendering - the geometries have to be convert=
ed into some objects understood by Java2D resp. Java3D. For example a spher=
e would need conversion to a
java.awt.geom.Ellipse2D (or a sub=
class) respective to
com.sun.j3d.utils.geometry.Sphere (or a s=
ubclass). These objects would then be reused every time the map/scene has t=
o be rerendered.
Actually Java3D could as well be used to render a "flat" map a= s every conventional MapCanvas does. However I'd suggest having a Java2D-ba= sed alternative for people that don't need 3D functions and therefore don't= want to have the Java3D libraries installed. (Which btw. are partly licens= ed under BSD and partly under Java Research License (JRL)/Java Distribution= License (JDL) for noncommercial resp. commercial use.)=20
In its current state, pure Java3D is neither intuitive to a geographer, =
nor is it geography-aware. It has no sense about "the earth" or c=
oordinate renference systems and their meaning. However it would be possibl=
e to create a thin wrapping API that hides the Java2D internals (such as Tr=
ansformGroups and the whole tree approach) and instead provides (geo)object=
The geographer would just add 3D georeferenced, = styled objects into the wrapped Java3D "universe" and define loca= tion and position of the viewer. The underlying implementation would care a= bout:
A point to check is how good Java3D could cope with SLD styling or styli= ng in general. I expect this to be rather tricky!=20
Who of the GT developers and other interested readers is f= amilar with Java3D? I am, but I am not an expert. Matthias= =20
Have there been articles already about using Java3D for st= yled geoobjects rendering? If so, please add here.=20
As well known, Coordinate Reference Systems (CRS) include the typical Ge=
ographicCRS and ProjectedCRS, but also GeocentricCRS, TemporalCRS and Engin=
eering CRS. So, in theory, when a 3D object constructor requires a
ordinateReferenceSystem object, any of these can be passed in. The i=
mplementation would need to either cope with them correctly or throw an exc=
eption (for example if a TemporalCRS is passed in).
Dealing with Proj= ectedCRS and GeographicCRS is fine: They usually have an axis pointing nort= h-south and one pointing east-west. The third one (if exists) points up-dow= n. Objects having such a CRS would produce a bounding box with these three = axes.
Problems arise when an GeocentricCRS is passed in. Although it would def= ind the location of coordinates as precisely and unambigously as do Project= edCRS and GeographicCRS, it would usually produce a bounding box in Geocent= ricCRS. This BBox would need conversion to some ProjectedCRS or GeographicC= RS in order to get (for example) merged with BBoxes of other map layers or = other features of other feature types of the same layer. However conversion= from Geocentric BBox to Geographic BBox (or back) is very inaccurate.= =20
Geog= raphicCRS. Problematic since there is no interface that covers both.=
GridCoverages are essentially flat, but with an elevation model qute thi= ngs can happen...=20
Use coverages as elevation models...=20
TINs are both geometrical objects (multiple 3D triangles) and coverages =
Java3D could render them as lattice model or as actual surface. N= ice to have.
Objects could move in time through the space or they could change their =
size over time. Some objects might have a start and end date between they e=
Java3D can cope with this. But the geometry API and the Ja= va2D rendering API would need to deal with this too. Just something to tink= about...
...go here. Feel free to add ideas how to best achieve the above.
= Or possibly there are better general approaches than the abov= e?