Author Topic: Beta released (Read 27284 times)

Krein · « **on:** February 02, 2004, 08:44:45 AM »

v1.54 (beta) has been released. If you are on the beta list, you should have gotten the email with download instructions and info on new features. If you'd like to beta test, send an email to beta@topofusion.com

If you're on the beta list, post topics here about bugs, ideas, comments, etc!

sanewcomb · « **Reply #1 on:** February 02, 2004, 12:39:05 PM »

Very good 1st go around. Noticed a few quirks (bugs) right away. Do you want them posted here, or by email?

If not too much effort, a full screen mode would be cool and help the user get that "full-immersion" virtual reality feeling

'>

Steve

sanewcomb · « **Reply #2 on:** February 02, 2004, 01:00:39 PM »

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?

Steve

Krein · « **Reply #3 on:** February 02, 2004, 01:02:52 PM »

Post any bugs here, preferably making a new topic. That way if others find them they know not to bother reporting them if someone else already has.

Thanks.

« **Reply #4 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.

Alan · « **Reply #5 on:** February 02, 2004, 01:55:59 PM »

So the answer is no, you can't view that additional level of detail (currently). We'll have to work something out for 10 meter DEMs.

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.

Alan · « **Reply #6 on:** February 03, 2004, 05:56:17 PM »

I take that back, it reduces the model so that the points are at least 10 meters apart, so it should be fine for 10m DEMs.

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.

sanewcomb · « **Reply #7 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.

Alan · « **Reply #8 on:** February 04, 2004, 12:55:45 PM »

I'll have to take a look at the code again. Some other assumptions made by the program come to mind, particularly in the interpolation (I was only working with 30m data at the time).

Alan · « **Reply #9 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).

sanewcomb · « **Reply #10 on:** February 05, 2004, 10:06:19 AM »

Alan,

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.

Alan · « **Reply #11 on:** February 05, 2004, 10:34:46 AM »

There aren't any limits on the size that I'm aware of. You're right that it only accepts UTM ground reference systems. I don't see a compelling reason to support others.

Why are you putting them together anyway? TopoFusion deals with the boundaries between them quite well.

sanewcomb · « **Reply #12 on:** February 05, 2004, 11:56:00 AM »

The seamless NEDs come off the server that way, either in an Arcview, GeoTiff or SPOT file. I can convert it to a DEM, but the coordinate system they use is geographic. I remember some time ago using a coordinate conversion program. Just have to find it. Thanks for the quick reply.

ddunne · « **Reply #13 on:** February 05, 2004, 11:58:39 PM »

This program rocks!

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"

sanewcomb · « **Reply #14 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.

Alan · « **Reply #15 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.

sanewcomb · « **Reply #16 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.

Alan · « **Reply #17 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.

sanewcomb · « **Reply #18 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.

Alan · « **Reply #19 on:** February 12, 2004, 06:30:14 PM »

My version of 3DEM (perhaps too old) doesn't open the NED files I downloaded.

Alan · « **Reply #20 on:** February 12, 2004, 06:35:04 PM »

Ah, looks like I downloaded the wrong format from USGS.

Alan · « **Reply #21 on:** February 12, 2004, 06:50:34 PM »

Quote (sanewcomb @ Feb. 12 2004,6:07)

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.

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.

Alan · « **Reply #22 on:** February 12, 2004, 07:09:24 PM »

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.

sanewcomb · « **Reply #23 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.

sanewcomb · « **Reply #24 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.

mikewager · « **Reply #25 on:** February 25, 2004, 10:50:47 AM »

I finally had a chance to play with the new beta version and really like the 3d options. Â I have had no problem downloading NED data in 1deg x 1deg chunks. I merge/subset and convert the data using Global Mapper. Â It will convert just about any DEM format (DTED, Geotopo30, SRTM ect) to USGS DEM format.

Thanks for the great program

Mike

sanewcomb · « **Reply #26 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.