Post by: Krein on February 02, 2004, 08:44:45 AM
If you're on the beta list, post topics here about bugs, ideas, comments, etc!
Post by: sanewcomb on February 02, 2004, 12:39:05 PM
If not too much effort, a full screen mode would be cool and help the user get that "full-immersion" virtual reality feeling
Steve
Post by: sanewcomb on February 02, 2004, 01:00:39 PM
Steve
Post by: Krein on February 02, 2004, 01:02:52 PM
Thanks.
Post by: on February 02, 2004, 01:42:24 PM
| Quote (sanewcomb @ Feb. 02 2004,1:00) |
| oh, I forgot why I was posting in the first place. The program loads 10m data files, but it appears the same as 30m files (as far as I can tell). Is there a way to view the additional elevation information? |
I'm not sure what you mean. If you have a 30M and a 10M covering the same area it will use one or the other, not both.
Just so you know, the program currently uses a static number of vertices in the mesh no matter where you are zoomed. It finds the elevation values of these vertices using bilinear interpolation. However, to avoid having too many faces of the same normal, it will reduce the size of the grid so that points are at least 30 meters apart (since it is assuming 30 meter DEMs). I haven't had time to mess with 10 meter dems much.
Post by: Alan on February 02, 2004, 01:55:59 PM
I should also mention a few other points. First, this release should be considered more of an alpha than a beta. There are still many things we need to add/fix before it would be up to beta.
For starters, when the program loads it enumerates all available DEM files. When elevation data from one of them is needed, the DEM is loaded into memory. At the present time, DEMs are never removed from memory, so you could potentially eat all your memory that way (I'm not sure how much each one takes up in memory, probably on the order of 1MB). We will need to add a cache of some sort.
Secondly, as you'll notice, there's no configuration dialog for 3d! For now, you're stuck with our defaults.
Also, we will soon add further integration of DEM data into other parts of TopoFusion. Some examples: 1) get the elevation at any given point on the screen (right now, you must be in 3d mode), 2) add DEM elevation to a track, 3) compare DEM and track profiles.
Post by: Alan on February 03, 2004, 05:56:17 PM
I've been playing with swapping a 10m and 30m of the same place and I too don't see much difference either, I guess that's just how it is.
Post by: sanewcomb on February 04, 2004, 09:54:42 AM
| Quote |
| I've been playing with swapping a 10m and 30m of the same place and I too don't see much difference either, I guess that's just how it is. |
I too played around with TF and same area DEM files and did not see too much until the resolution was around 1-2m per pixel. And it wasn't alot.
However, I think TF is throwing away significant amounts of the 10m DEM info. Here are some snapshots of another program's representation of the DEM data:
http://mywebpages.comcast.net/steve_n....nap.jpg
http://mywebpages.comcast.net/steve_n....nap.jpg
Here are VRML representations of the same data if you'd like to take a closer look:
http://mywebpages.comcast.net/steve_newcomb/topofusion/AC10Meter.wrl
http://mywebpages.comcast.net/steve_newcomb/topofusion/AC30Meter.wrl
On the whole I think the 30m data works fine for TF's viewer and it will be much easier to compile a wide area single DEM file of this resolution. If you have the time and it's easy, throw in a parameter for the grid size of the model so 10m (or even higher res in the future) DEMs are shown in their full res.
Post by: Alan on February 04, 2004, 12:55:45 PM
Post by: Alan on February 04, 2004, 06:16:28 PM
| Quote |
| However, I think TF is throwing away significant amounts of the 10m DEM info. |
Right, much of the data is "thrown away". It uses a fixed number of vertices in the mesh. It's currently set to 20,000 vertices, which is way too low (at least for my hardware). This is one of the first things that will be configurable.
The issue with how this should be set is more dependent on how fast you want to be able to switch to 3d mode than on how many FPS you want. I kept it low to make switching very fast. A much more advanced method would load a rough model very quickly and then increase the complexity in the background. The biggest slow down initially is loading the DEMs into memory (has to be done no matter the complexity).
Post by: sanewcomb on February 05, 2004, 10:06:19 AM
Are there any limits to the size of the DEM file? I've put together quite a few for Tucson, but nothing shows up. It's 3464x2518. It loads up in a different viewer. In a related issue, does the DEM have to be of a certain type? This file is in the geographic coordinate system, where as TF seems to only want UTM based ones. Thanks.
Post by: Alan on February 05, 2004, 10:34:46 AM
Why are you putting them together anyway? TopoFusion deals with the boundaries between them quite well.
Post by: sanewcomb on February 05, 2004, 11:56:00 AM
Post by: ddunne on February 05, 2004, 11:58:39 PM
This is the best visualization tool I've ever seen for GIS data - combining incredible flexibility in its ability to obtain data, now with 3D rendering that outperforms every commercial solution available.
A few notes:
- as the number of dems files inreases, response decreases dramatically, (system mem goes up big time.) The coolest part of this app is the way it caches locally, allowing rapid viewing cumulatively. I'm stacking up dems data, but as i do, things are starting to really crawl. - some way to load/unload selectively?
-active display area in 3d rendered - would be nice to manually reduce/enlarge displayed area, (i.e. - my 128Mb graphics card cooks - i can hande ALOT, but my buddy's integrated 32Mb video is struggling...)
- "would be nice" some kind of hard stop to rotation at the perceived horizon, (not very valuable to view topo data from "underground"
Post by: sanewcomb on February 06, 2004, 02:14:40 PM
| Quote (ddunne @ Feb. 05 2004,11:58) |
| -active display area in 3d rendered - would be nice to manually reduce/enlarge displayed area, (i.e. - my 128Mb graphics card cooks - i can hande ALOT, but my buddy's integrated 32Mb video is struggling...) |
You can do this by zooming while in 3D, then refreshing with the 'r' key. I zoom with the wheel on the mouse. Also use the 'r' key after moving the map with the right mouse button.
Post by: Alan on February 08, 2004, 05:43:57 PM
| Quote (ddunne @ Feb. 05 2004,11:58) |
| - as the number of dems files inreases, response decreases dramatically, (system mem goes up big time.) The coolest part of this app is the way it caches locally, allowing rapid viewing cumulatively. I'm stacking up dems data, but as i do, things are starting to really crawl. - some way to load/unload selectively? |
There will be a cache similar to the tile cache in the next beta.
| Quote (ddunne @ Feb. 05 2004,11:58) |
| -active display area in 3d rendered - would be nice to manually reduce/enlarge displayed area, (i.e. - my 128Mb graphics card cooks - i can hande ALOT, but my buddy's integrated 32Mb video is struggling...) |
Steve's comment about the 'r' key is about the only thing I can suggest at this time. The next beta will have user-selectable model complexity, but unfortunately the texture itself will still be limited to what is shown on your screen in 2d mode (no increased resolution), for now.
| Quote (ddunne @ Feb. 05 2004,11:58) |
| - "would be nice" some kind of hard stop to rotation at the perceived horizon, (not very valuable to view topo data from "underground" |
We could add an option for that. It's useful for when your floating GPS track goes 'inside' the model.
Post by: sanewcomb on February 11, 2004, 03:12:54 PM
| Quote (Alan @ Feb. 05 2004,10:34) |
| You're right that it only accepts UTM ground reference systems. I don't see a compelling reason to support others. |
You might consider adding at least one additional DEM coordinate system to TF, the geographic one used by the seamless National Elevation Data set. It also involves a few conversions, but at least you can point to a map and get the whole area you are interested in one shot.
The problem with converting the geographic system to UTM is once the area is rotated and converted, adjacent areas no longer are seamless. It's ok if the area you're intersted can be downloaded in one chunk.
Check out the server for getting the geographic coordinate NED data.
http://seamless.usgs.gov/viewer.htm
click on the United States Viewer link. There are several resolutions available and several file formats. GeoTIFF works with many viewers/converters but BIL is by far the most efficient. I think the entire Grand Canyon downloaded in less than 6 MB compressed and converted to over 50 MB DEM file.
Biggest advantage to this server is the graphic interface and ability to grab the whole area at once with no knowledge of quad names.
Post by: Alan on February 12, 2004, 12:09:40 PM
| Quote (sanewcomb @ Feb. 11 2004,3:12) |
| You might consider adding at least one additional DEM coordinate system to TF, the geographic one used by the seamless National Elevation Data set. It also involves a few conversions, but at least you can point to a map and get the whole area you are interested in one shot. |
What are you using to convert the NED files to UTM? In a few searches I came up with nothing.
| Quote (sanewcomb @ Feb. 11 2004,3:12) |
| The problem with converting the geographic system to UTM is once the area is rotated and converted, adjacent areas no longer are seamless. It's ok if the area you're intersted can be downloaded in one chunk. |
I'm not sure I understand this. What adjacent areas? If you use the USGS download thing to download two different chunks, the 'seamlessness' of it is reliant on your ability to draw rectangles. What does it have to do with converting geographic to UTM?
| Quote (sanewcomb @ Feb. 11 2004,3:12) |
| Biggest advantage to this server is the graphic interface and ability to grab the whole area at once with no knowledge of quad names. |
True enough, though I don't much like that interface.
Post by: sanewcomb on February 12, 2004, 06:07:39 PM
| Quote (Alan @ Feb. 12 2004,12:09) |
| Quote |
| What are you using to convert the NED files to UTM? In a few searches I came up with nothing. |
3DEM
| Quote |
| I'm not sure I understand this. What adjacent areas? If you use the USGS download thing to download two different chunks, the 'seamlessness' of it is reliant on your ability to draw rectangles. |
The chunks that are downloaded are self consistent. No problem with that. The max you can download is 100MB. The viewer breaks the files into pieces automatically. But when they are coverted to UTM, the program I use (above) clips the edges (rotation is always involved) and saves the resulting DEM as a rectangle, with 90 degree angles. These UTM rectangles are not seamless with each other. I guess you could resort to areas less than 100 MB, and then overlap them enough so TF has enough data to fill in the gaps.
I don't know of any other program that converts from geographic to UTM, except maybe Grass5. Haven't had the time to fool around with that one.
Post by: Alan on February 12, 2004, 06:30:14 PM
Post by: Alan on February 12, 2004, 06:35:04 PM
Post by: Alan on February 12, 2004, 06:50:34 PM
| Quote (sanewcomb @ Feb. 12 2004,6:07) | ||||||
3DEM
The chunks that are downloaded are self consistent. No problem with that. The max you can download is 100MB. The viewer breaks the files into pieces automatically. But when they are coverted to UTM, the program I use (above) clips the edges (rotation is always involved) and saves the resulting DEM as a rectangle, with 90 degree angles. These UTM rectangles are not seamless with each other. I guess you could resort to areas less than 100 MB, and then overlap them enough so TF has enough data to fill in the gaps. |
This still makes no sense at all to me. When I download an area from http://seamless.usgs.gov/viewer.htm I get exactly the area that I drew a rectangle around. I see the option to break it up into sizes of 25/50/75/100, so what? If I've already downloaded the lower half of the catalinas and I go back to download the upper half, I've got to do significant overlap or there will be a significant gap, right?
This seems to be independent of the coordinate system (UTM/geographic) to me.
I obviously don't know enough about the seamless server and its formats, but I'm not sure that I want to.
Post by: Alan on February 12, 2004, 07:09:24 PM
Post by: sanewcomb on February 13, 2004, 08:02:44 AM
| Quote |
This still makes no sense at all to me. When I download an area from http://seamless.usgs.gov/viewer.htm I get exactly the area that I drew a rectangle around. I see the option to break it up into sizes of 25/50/75/100, so what? |
If the map isn't broken up, then it will display fine as one DEM file. It is only when it is broken into smaller files that those files do not line up. I would agree if you are going to define each download using the rectangles (avoiding the automated splitting), then you would need to overlap them a fair amount anyway. The problem occurred for me when I wanted to download the entire Grand Canyon area. Can't be done in less than 100 mb. Also, this site provides higher res DEMs in some areas.
Question: When DEMs overlap, how does TF handle it? One file will define the elevation as 0 (or possibly -9999), the other correctly. How does it know which one to use?
| Quote |
| If I've already downloaded the lower half of the catalinas and I go back to download the upper half, I've got to do significant overlap or there will be a significant gap, right? |
The gap comes about because after the NED file is converted to UTM coordinates, it is rotated somewhat. But the file is saved as a true rectangle with 90 degree corners. I'm not sure at this time whether some of the elevation points are clipped to make a rectangle of the same size (before and after converting), or whether TF is creating the gap by reading 0 height data points from one of the files.
| Quote |
| I obviously don't know enough about the seamless server and its formats, but I'm not sure that I want to. |
The format that is easiest to use is GeoTIFF. The default format is ARCView, which I haven't figure out a way to convert. BIL is the smallest download size.
Post by: sanewcomb on February 13, 2004, 08:34:58 AM
| Quote (Alan @ Feb. 12 2004,7:09) |
| Also, the dem file produced by 3DEM is not 'geographic reference system'. It is code 3 which I've been unable so far to find out what it means. |
This may have to do with the version you are using. I've tried ver 18.6 and 15.7. The info after the header is 1 1 0 if you don't convert to UTM coordinates first. The 0 indicates geographic coordinate system and it uses lat/lon throughout the file.
Post by: mikewager on February 25, 2004, 10:50:47 AM
Thanks for the great program
Mike
Post by: sanewcomb on February 29, 2004, 12:08:21 PM
| Quote (mikewager @ Feb. 25 2004,10:50) |
| I merge/subset and convert the data using Global Mapper. |
This is a nice program, but for $179 it's a bit steep for just converting data sets. I will post a message soon about the way different DEM data sets are displayed in TF.