|
|
|||||||
| Feature Discussion Education, discussion and proposals of WWJ features |
Topic Review (Newest First)
|
| 11-01-2010 06:41 AM | ||
| nlneilson |
Hi James, good to see your getting the Java version. I tinkered with with the WMS and splitting a large image into tiles, much slower and more problems than having the image pre-tiled. It seems strange WWC# works and WWJ is giving problems, the tiles should be the same. I pulled images from the WWC# server using WWJ as well as the WWJ server. |
|
| 10-26-2010 04:12 PM | ||
| James_In_Utah |
I wish WWJ could read tiles from a tile server the same way WWC# could. We don't have a WMS on our closed LAN, but we do have a tile server and I've been unable to use WWJ there. James |
|
| 10-20-2010 08:00 PM | ||
| markthetser |
No excuse  So since this is a feature request forum, my feature request is to make the names of Airspace and SurfaceObject (and their children) consistent. Plus revisit other class names to remove Aeronautics terms from generic concepts. I am sure most will say it is too much work for not much gain, but I am hoping someone is paying attention to the need for accurate/consistent names. |
|
| 10-20-2010 07:19 PM | ||
| heidtmare |
agreed. It is National Aeronautics and Space Administration, so they like to throw airspace in there as much as possible
|
|
| 10-20-2010 07:03 PM | ||
| markthetser |
Yup, I was getting hung up by the "Airspace" term. I, in fact, did use Airspace Boxes, Spheres and Cylinders in my prototype app. The term SurfaceObject makes perfect sense to me. Along with SurfaceCircle etc... but Airspace just seems like the wrong term (one immediately thinks of airplanes). If Airspace and SurfaceObject are intended to be the basic drawing objects that I should use, the concern I have is that they are very inconsistent. The names Airspace and SurfaceObject show no consistency and even the children SphereAirspace vs SurfaceCircle are not consistent (the shape is a prefix in one and a suffix in the other). Please consider improving the consistency because that would help make WorldWind easier to learn and use. |
|
| 10-20-2010 06:46 PM | ||
| heidtmare |
I think your getting hung up on the "Airspace" term. its just a word used to divide similar renderables into a grouping based on their intended pourpose. Airpaces were designed to put 3d shapes above the surface(in the air) instead of on the ground like SurfaceObjects. They can however have their bottoms anchored to the surface. They can be styled to your liking and there is even an example in the src with a movable sphere. |
|
| 10-20-2010 04:45 PM | ||
| nlneilson |
Quote:
2. Airspaces is in the SDK, what more do you expect before it would be considered in the core? Consider "Airspaces" to be your "3D graphics". You can also use openGL (jogl). There are many posts covering this. Get used to the "Search" on the forum, most questions/problems/etc. have been covered. That is what I use first, it has been a great help. |
|
| 10-20-2010 03:47 PM | ||
| markthetser |
Given that my options are: 1) Use airspaces to get a movable 3D box (when my application does not deal with airspaces) or 2) Implement my own movable This indicates to me that the framework either a) Has only Airspace-centric applications in mind or b) Is not yet mature. This would mean that everyone who uses WorldWind to draw 3D graphics on a map will have to make the same choice. Ideally the movable 3D graphics would be implemented right in the WorldWind core and the Airspaces would make use of them. That way other apps can also make use of the core functionality. The question this raises in my mind is "If I have to implement my own moveable 3D graphics, what else will I have to implement that is not supported by the core." This would mean that using WorldWind is risky for my application. On a related note, implementing Movable means that all instances are moveable. I need to be able to turn on/off movability at an instance level. For example, I would like to make one sphere moveable (draggable by the mouse) but another sphere immoveable (not draggable by the mouse). Here again I can implement this myself, but that also reenforces the riskiness of using this software. |
|
| 10-20-2010 02:34 PM | ||
| heidtmare |
if you have to have a 3d box then you need gov.nasa.worldwind.render.airspaces.Box all airspaces implement Movable. If you have a different renderable that you want to implement Movable on, its very easy just to extend and implement it. Ive done that with marker in the past, but later switched to using UserFacingIcon which is natively movable, and now im moving to PointPlacmark where i'm going to have to implement Movable again. I agree that pretty much every renderable should implement Movable natively, but its not a show stopper. |
|
| 10-19-2010 09:41 PM | ||
| markthetser |
Markers are 3D shapes but are not Movable and there is no Box SurfaceShapes (such as SurfaceEclipse) are Movable, but are not 3D shapes (they are only surface objects). I would like 3D shapes that are Movable Help? |
|
| This thread has more than 10 replies. Click here to review the whole thread. | ||
