Messages

ahhh... i think i know what you're talking about. Go to TOOLS, OPTIONS, 3D VIEW tab, then set Elevation Exaggeration to 0.01 (the default is 1). Does that make it better?

That does the trick!  But this is odd: the lower limit, cited right there in the dialog, is 0.5.  Yet GE didn't complain at all when I typed in 0.001, and the image is truly flat! 

What a contrast to GE's normal obtrusive, over-zealous limit checking! E.g., when you are typing in the lat/lon limits for a bounding box, if you make one error, it resets everything to some bizarre default, rather than give you a chance to edit.

Thanks!

Even with the new USGS NED server, you may still have to turn the DEM files from a supplied format (like flt) to tif for DEM2TOPO. I used a batch file I got at the USGS, which in turn requires and installation of the gdal utilities.  Much of the instructions were written when the USGS seamless server supplied tif (Geotiff)-- that server is mainly gone.

I'm using this process for areas outside the USA, where the are no good topo maps, or the available maps are off.  I've even found places in Nevada where the available garmin-compatible maps are off. I'm also interested in some of the newer data, which may resolve some massive errors in the USGS database (e.g.: http://www.summitpost.org/picacho-usgs-map-errors/845687/c-837597).

Even the view forced to a perpendicular is not "2D." If I rotate the page to a totally normal view of the earth, if there is any terrain model, the view is as if there were perspective,  so the segments of the grid are now slanted.  I've tried all the clamping options, none seem to make any difference.

Good point.  I wonder how that applies to GPSMapEdit, which displays googleMaps data in its own interface?

"8.3 Content License. Subject to these Terms (including but not limited to Section 9 (License Requirements) and Section 10 (License Restrictions)), Google gives you a personal, worldwide, royalty-free, non-transferable, non-assignable, and non-exclusive license to access, use, publicly perform and publicly display the Content in your Maps API Implementation, as the Content is provided in the Service, and in the manner permitted by the Terms. Specifically, you understand the following:

(a) Content (including but not limited to map data, traffic, directions, and places) is provided for planning purposes only. You may find that weather conditions, construction projects, closures, or other events may cause road conditions or directions to differ from the results depicted in the Content. You should exercise judgment in your use of the Content.
(b) Certain Content is provided under license from third parties, including Tele Atlas B.V. ("Tele Atlas"), and is subject to copyright and other intellectual property rights owned by or licensed to Tele Atlas and/or such third parties. You may be held liable for any unauthorized copying or disclosure of this content. Your use of Tele Atlas map data and certain other Content (including certain business listings Content) is subject to additional restrictions located in the Legal Notices page."

It used to be easy to force google earth to true 2d view.  For example, if you uploaded a rectangular grid, the 2d view would show perfect rectangles, so it was easy to make tiles for a larger jpeg map. 

The current release of GE insists on showing you the rectangles distorted by perspective.  Is there any way to force true 2D?  Do I have to roll back my installation -- how far?

I ended up just registering graster for $5!

I see inconsistent advice on this front.

Garmin website claims 1 megapiaxel for x*y is the limit, others claim the tiles must be square 1024*1024. Garmin gives example like 512*2048, which leavels we to wonder in non-power-of-2 values are usable (e.g. 666*1500).

And while we are at it... do you know a good reference for making custom maps with several tiles in one kmz, as in Goggle Earth?  Thanks

In areas that overlap with the US, the usgs will supply 1/3 arc-second. Some of these seem to be interpolations on much of the Mexican side, but others do have the detail one expects for 1/3 arc-second (based on comparisons with the GE images.

I used to work for a company that occasionally would contact finer detail satellite (LiDAR) from commercial vendors... back in the days when cost was not an issue. ;^)

I've had success making maps for some rather small areas in Mexico, near some peaks I wish to climb.

One area has me stumped.  I started working with USGS 1/3 arc-second data for the region around Cerro Pinacate (within 31 to 32 lat, -113 to -114 lon).  I've gone through two processes -- 1) splitting the single usgs DEM into tiles, contouring them under DEM2TOPO, and reassembling the tiles under GPSMapEdit; and 2) using gdal_contour to make shapefiles (without splitting the original USGS dem), which I then import into GPSMapEdit. The files look OK under the map-making programs, and the contours show up just fine in BaseCamp.  But when installed on the 62stc, only linear features (like roads) show up -- no contours at all.

There are some bizarre bits of contouring, which show up when I go through either process.  I'm guessing something is not quite right with this DEM.  I've used the Google Earth overlay in GPSMapEdit, and there is absolutely no real feature to account for these bizarre contours.


Any ideas?   I could breakout the compiler and start processing the DEM; I suspect there must be some oddities.  I tried playing with the -snodata  -- no changes.

Truly bizarre -- in the last section, I got a degree by degree block that spanned USA and Mexico. Contours were OK in USA, but were displaced over the border.  Two degrees over in Mexico, contours were fine.

I figured that out -- looked at the source, and realized that they were complied into the executable.  I just got a newer distribution, and made a map directly via gdal_contour, by creating shapefiles for the major and minor contours.  The result is interesting -- I'll compare this new map with that made by dem2topo.  I've just started exploring gdal_demo, so I don't know which options exist to smooth the contours, etc.

A bad thing about gdal_contour: it leaves blocky angular lines at the finest scale (no smoothing for contours, so it seems -- so far).  The good thing: you can directly handle much larger maps than you could by dem2topo -- a 10812x10812 geotiff, for example.

Do you know where I might find this driver (from title)?  There is a GDAL page for drv_shapefile, and maybe even find c++ source, but I was hoping not to build the entire package from scratch.

I decided to try gdal_contour, but apparently need the shapefile drive... the package for Windows doesn't seem to have anything but exe files, and I really can't tell if the drivers are embedded in one of those.  I don't even know what extension I'm looking for. I just spent about an hour cruising the web for a pre-made version of the driver package for windows.

I did geological mapping with a sighting Brunton compass (about $500 in 1978), and navigated 8 wihiteouts by map and compass alone. I always carry backup map and compass with me.

And I find the GPS is superior and vastly more convenient.  I have this vivid memory from a whiteout in 1983, with blowing snow and 50 mph winds. I got the map, carefully folded it into a small rectangle inside my pack, took it out in the light, and had the wind mercilessly rip it to shreds.  I have navigated two whiteouts by GPS since, and it seems so vastly safer and easier.

I carry the gps very high on my body, so I get better signals in canyons... but if you are in a very deep canyon, you don't really have a lot of choices where to go, do you?
http://hwstock.org/RainGunJuniper13/html/DSCN2826.htm

I often get asked the question "but what do you do when the batteries run out?"  Well, I generally don't start out unless the unit has freshly-charged 2900 mAh NiMH; and when it does run low,  I take out the 2 Li metal batteries that I always carry in my pack, and replace the old batteries.  The need for field replacement has occurred 4 times in over 800 trips with the GPS.  Li metal has a long shelf life and operates well in cold.

Sometimes when I'm in the outdoors, a person will start to wax poetic about the superiority of the compass. I ask that person a simple question: do you know what the declination is here?  Now, in this year?  I've never had anyone able to answer that question correctly.  Most people simply don't know how to use a compass, except to get a vague feeling of where north is.  If you know how to use a compass well, good on ya; you are in a minority.

Datum issues were my first guess; but the misalignment doesn't match the expected offset (for e.g. NAD27 vs WGS84), and the datum is supposed to be wgs84 or close equivalent-- datum seems to be hard-wired into these files, and by the normal processing, I don't get the option to change it.

I just tried the NASA ASTER dem, and the misalignment disappears -- but the data give a blobbier image, even though they are supposed to be 1x1 arcsecond^2 as well.

I'm working on a Garmin topo map for the region between lat 32 and 33, and long -115 and -116. I've used the USGS shapefiles for the streams, and have tested both the 1 arc-sec and 1/3 arc-sec DEMs from the national map server.  I process the DEMs from gridfloat files to GeoTiff, then use dem2topo to make the mp files, then GPSMapEdit to put it all together. (For the 1/3 arcsecond data, I used gdal_translate to split the 1degreex1degree file into 16 blocks, which I eventually reassembled in GPSMapEdit.).

The region is about 1/4 above the US-Mexico border, 3/4 below. Above the border (in USA), the topocontours agree well with the coordinates of benchmarks (on mountains), with GoogleEarth imagery, and the streams line up with the valleys highlighted by the contours.  But for every place I can check in Mexico, the contours seem to be shifted about -60 meters in the x direction, and -60 meters in the y direction. In Mexico, the nhd stream polylines data line up with google earth stream imagery (within the limits of simplification),. However, the streams are not in the valleys defined by the contours, and the few confirmed waypoints I have on mountains don't line up with the mountaintops as defined by the contours.  The same holds if I use the 1 arc-sec DEM or the 1/3 arc-sec DEM.

Since I downloaded these data all in one chunk from the National map server, this discontinuity seems a bit strange.

Questions:
1) Do you have any idea of the cause?  I would blame the software, but the agreement in the USA argues against that.  Unfortunately there are no border area ridges (that I've yet found) with enough regularity to show the discontinuity.

2) Is there a list of Mexican benchmarks -- on well-defined points, such as summits -- that I might use to quantify the problem better?

I last made a map for a mountainous area in N Baja, and the summits were so sharply defined in that area, that the misregistration of the contours was obvious.  There it was also an error of about 60 meters, but almost entirely along the x direction.

Thanks. I hope you can follow this!