Topics

This look like the same sort of error I found 2 years back for the NV maps near Desatoya Twins

Below is a screenshot for ExpertGPS of tracks that I know go to the summit of Humphreys Peak; check the dark blue track:
http://hwstock.org/err/realhump.jpg

Now here is the screen shot for the same track on the Garmin 62sc:
http://hwstock.org/err/62stc.jpg

The caltopo map contours are displaced by about 300' in x-y



I haven't figured out what caused the error.  The contours for nearby Mt Emerson are right on the spot; that's on the next topo sheet (24k) south.

I've seen many older character maps posted, and those older posts showed a fairly close correspondence between the symbols as displayed in GPSMapEdit, and the way the symbols displayed on the actual GPSr.

I'm a little puzzled with the Marine Navaids, however.  I've used a basic blue navaid in many applications, and the symbols always translate to a round blue filled circle.

GPSMapEdit has at least 3 choices for "Navaid, blue" all with different hex codes, all showing on the GPSMapEdit selection menu (v 1.1.75.2) as blue filled circles surrounded by 6 rays. It seems like every one produces the same result on my 62stc -- what looks like a blue exclamation point tilted at 45 degrees (NE), with the "dot" on the waypoint location.

I wouldn't mind if the symbol showed up on the GPSr as either a simple filled blue circle, or a filled circle surrounded by rays.  Before I make a symbol map, is there some place I should look for this info?

UPDATE:  I just made an mp with a whole slew of symbols, checked it on the 62stc.  Nothing looks remotely like a navaid blue. The "navaid blue" symbols form GPSMapEdit show up on the 62stc as variations on the exclamation point theme.  The various city symbols show up as small dots varying down to very small dots.  Many symbols don't show up at all.

I'd really like files that have similar appearance of modern Garmins of varied type, so I don't want to peg appearance to another file that must be loaded on the gps... folks have a hard enough time with installing the maps!  Thanks

My 62stc had the power button fail after 15 months of use -- purely mechanical, it just started requiring harder and harder presses to turn on the unit.  I could still communicate with the unit via the USB connection.

I've known several other people who have had the same issue with recent garmin units; this just seems to be a problem of poor manufacturing and quality control.

In any case, I sent the unit in for replacement by a refurb ($110 plus shipping).  While waiting for the new unit to come back, I talked with several people who had bad experiences with Garmin refurbs.

When I got the refurb unit and turned it on, it immediately came up with "cannot unlock maps."  I called garmin, and they said this was a common problem with stc units, they forget to unlock the 100k maps that are supposed to come with a 62stc, or just corrupt the unlock code. WTF?  Don't they do the minimal, most basic checking of the unit -- e.g. making sure it turns on without errors, before sending it out? It doesn't take a genius to know there is something wrong with a unit when it displays an error message immediately upon power-up.

I've collected perhaps 5 stories from people who had serious problems with their refurb units.  Is this a remarkable coincidence, or had Garmin added unspeakably bad QA/QC to their reputation for unspeakably bad manuals?

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 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

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.

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'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!

I've just used the USGS server to get 1 arc-second DEMS for Mexico. These work (with some reregistration), but I'd like at least 1/3 arc-second.

I just need fairly small areas-- like a 24k quad-worth.

Have you folks ever tried the commercially-available DEMs?  I'm guessing they are pricey. Examples:
http://www.landinfo.com/products_dems.htm

Howdy -- I've made a img (garmin) format map for an area of Baja, Mexico, in the bounds of 30 to 32 degrees north, 115 to 116 degrees west.  I used the process given in this site's tutorial (downloading data from the USGS NED server, converting gridfloat to geotiff via usgs and gdal utilities, stepping through Dem2topo, then gpsmapedit and cgpsmapper). I have some exact gps waypoints from the area, and can confirm that the countours are displaced approximately 200 feet west of the actual positions.

I assume that somewhere in the process, I can use obe of these clever programs to displace the contours 200' east, so they will coincide with the actual terrain.

Any idea where I would add this displacement (and how)?  It looks like the affine translation GPSMapEdit will work, but it looks bizarrely ungainly for my needs-- I really don't need 3 pair of points, I just need to displace the map in a well-known direction.  I don't want the imprecision of picking points off the map in GPSMapEdit.

I'm sure this error is real, because I previously bought the cartografia garmin-compatible maps for all of Mexico, and also looked over the competitors' garmin-compatible maps for that area.  Both were displaced by about 200'. I contacted the technical people at cartografia, and they confirmed the 200' displacement in that area, and were kind enough to fix the maps and send me the update.  However, I've found that some of the areas of interest for me in Mexico have similar displacements, probably due to some mismatch in datum or whatever. I'd like to make custom maps of those small areas, and correct them for the displacements.
===
EDIT: I figured out how to do it in GPSMapEdit -- pretty simple in the end.  Just make a gps file with 3 waypoints near edges (and not colinear!), and make 3 more that are displaced by the exact same amount.  Then add that gpx file to the project, and use the points to do the affine mapping by drag and drop. Worked like a charm.

The recommended NV 24k maps have a registration error for one region of central NV near the Desatoya Twins (east of route 50, WSW of Austin).

I'd like to show you exactly where, but this brain-dead BBS software will not allow me to post external links

This looks like a datum error when the contour map was created from the DEM.  I have used the NV 24k maps in many parts of Nevada, and this is the 1st error that I have seen.

E-mail me if you want to undeniable examples of the error.