Welcome, Guest. Please login or register.

Login with username, password and session length
Forums Search:  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - nm_map_user

Pages: 1 [2] 3
I second Seldom opinion, the reason for double lines is using transparent 'Y' maps in Mapsource. Stright lines are from preview map, which is visible over areas without background objects.

Other effects are probably a result of processing details, of which we haven't any informations. Just an example - if you recompile your map, changing transparency from Y to S, you can still view old map in Mapsource, since Mapsouce can use data from cache.

I've bee wondering if I've been seeing cache effects because sometimes I don't see changes I'd swear I made. Is there any way to force MapSource to clear the cache, or do I have to change the map name on each test? Is it enough to change the mapset name, or do I have to change the tile ID as well?

Not sure about that brown and blue houndstooth check in your bottom image, but try Transparent=S instead of Transparent=Y.  I always used Transparent=S when I was doing overlay maps, and it covered up those generalized shapes.

Transparent = S didn't make a difference.

I've been doing a lot more experimentation and the issue seems to be the complexity of the map. I can make a simple map of the same extent and not get the hounds tooth. I can take the data that I'm using for the example above and select a smaller region and get a good map. I've tried increasing the TRE_SIZE, nothing changes. I've tried adding layers with the details only on the 0 layer with just gross detail at the next layer - still get the hounds tooth. An obvious solution is to split the map into tiles, but it doesn't seem like an excessive amount of data when I look at some of the topo map tiles.

Update: I split the map in half and now it seems to work. For what it's worth, the map spanned 1 40', split it spanned 1. Not only did it solve the problem with the background, the extra lines disappeared, and the jaggies in lines also disappeared. Probably not a coincidence - the NM Topo mapset in the custom maps on this site also has tiles that are 1 wide.

Update: Spoke too soon - when I zoomed in close enough on the 1 wide map, the hounds tooth appeared. Not sure if it was a factor the width or where I was looking in the map. I've now extracted a small region in the north west corner and get the hounds tooth at all zoom levels. Other problems that are showing up - one class of my polygons doesn't appear in MapSource, the class that does appear (and has the right color), but has no tooltip value, even though it's set in the .typ file. The roads are type 0x30, but appear in the color of type 0x03. I've checked the .mp file and the types are correct in the file.

I thought I was beginning to understand this stuff, but now the mysteries are multiplying.
I backed up and created what I thought as a simple map, importing a shapefile of roads into GPSMapEdit. All the roads are imported as type 0x000a (unpaved) at level 0. I add another level (otherwise I get an error that about generating the preview). Here are the various settings:

And here's what a small piece of the map looks like in GPSMapEdit

Here's the corresponding region in MapSource - notice the extra straight lines. What are these? They appear to be some sort of simplification of the curves, but why are they there? They seem to relate to my zoom levels, but how?

And the final kicker - when I zoom out, I get this:

I've tried this process numerous times, tweaking zooms, changing type, use of external .typ file, etc, and keep getting this nonsense. I've been careful to delete all my intermediate files (rename outputs) so I know I'm seeing the results of my new run. I suspect these are newbie errors that are familiar to the more practiced, but I'm baffled.

I went back and read over the tutorial on making topo maps, figuring that the answer would be there somewhere, and indeed it was. When you import a shapefile, the first dialog screen that pops up asks for the type of the imported objects. I kept missing that there was a tab within the dialog to pick either "From list" (default) of "From field". The latter is just what I was looking for.

Here's a concrete example -
I have a shapefile containing three different classes of roads, which should be displayed on the map using three different symbolizations. The roads are distinguished based on a field value in the shapefile. I haven't been able to find any way to select just one class of roads in GPSMapEdit in order to set the type. Nor can I find a way to import only one class of roads on import. Am I missing something?

(I know that I can use other tools, like ArcGIS or qgis, to split up the shapefile or use a text editor on the .mp file, but I'm asking if there's a way to do it within GPSMapEdit)

Map Making Support / Re: How do multiple .typ files interact on GPS
« on: April 25, 2013, 06:26:09 PM »
The FID numbers being the same is what associates the custom .typ file with the compiled finished map.  Different MapSets must have different FID numbers.

Is there a master list of Family IDs to prevent collisions? A lot of my interest is in overlay maps that provide additional information on top of general topo maps, so in my case just avoiding the FID of the Garmin commercial products and the topo sets from this website will let me avoid problems. A similar question relates to numbering the individual map tiles. From what I've read, they have to be distinct across all maps loaded into the download? How do you avoid conflicts?

What is the impact of the Product Code within the Mapset?

Map Making Support / How do multiple .typ files interact on GPS
« on: April 25, 2013, 04:00:16 PM »
Let's say I make a new mapset with a custom .typ file. This mapset is transparent and is intended to be used as an overlay on standard garmin maps.  From what I'm reading, the gmapsupp.img file has the .typ file merged into the file. Can it have more than one? If gmapsupp.img is produced from multiple mapsets, are the .typ files merged somehow? What happens if there are collisions in codes?

UTM zone 12 is between -114 and -108, UTM zone 13 is between -108 and. -102.

Sorry, that was a typo in my original message. But that still doesn't seem to explain my I'm getting the garbage coordinates in the output of cgpsmapper when MapSetToolbox calls it to generate the preview image.

Looks like operator error :-(
On import, GPSMapEdit displays "Transverse Mercator" as the projection. In my first attempt, I accepted this value. I now went back and looked more carefully and realized there is an option to select UTM North, which then opens a window allowing me to select Zone 13. Now it works.

But along the way, I thought I'd try converting the shapefile to WGS84 to eliminate any confusion over projections. I'm pretty sure I made this work before. I convert to WGS84, then import that new shapefile into GPSMapEdit, selecting the same value object type for the lines and the same field for the labels as I did for the UTM data. I select Latitude/Longitude for the coordinate system, and leave WGS84 as the datum.
I set the map properties, save the .mp file, then run cgpsmapper. Runs successfully.

I now open MapSetToolKit and follow the same steps as I did for the .img file that started with the UTM shapefile. I select a different Product Code, then execute. The .pv file is generated, the preview .mp file is generated, but cgpsmapper dies on bad coordinates in the preview .mp file. I'm more confused than ever.

I'm getting the "error 107 can't parse coordinates" error.
GPSMapEdit is producing a .mp file that compiles just fine. However, MapSetToolKit is producing an .mp file for the preview that is nonsense. Structurally it looks OK, but the coordinates are a mess. Some values are apparently correct lat/lon. Others are just garbage. For example, the first line (where cgpsmapper fails) has:

The shapefile that I imported into GPSMapEditor is in UTM 12N, which is between -107 and -108 longitude, and the data happens to be between 36 and 37 degrees north. So, the last coordinate is pretty good, the first has a plausible longitude, and the other values make no sense, not even as UTM values.

Presumably this is indicative of MapSetToolkit creating a bad .pv file that is used to generate the .mp for the preview image, but I don't see how to fix it.

Map Making Support / Re: Creating installer using Inno
« on: April 23, 2013, 06:23:11 PM »
I just downloaded Garmin MapConverter and verified what the description appears to say - it will only convert mapsets that are already installed. So, unless you want to install the mapset just to convert it, stick with JaVaWa Mapconverter.

If you select convert and install, JaVaWa will place the maps in C:\Program Data\Garmin\Maps. However, the maps will also work in \users\<user-name>\AppData\Roaming\Garmin\Maps, which strikes me as a much better place for them (though I suppose they probably won't be found by other users on the same computer.)

It's possible to remap the colors of the entire NLCD in one shot using gdal_translate. The basic idea is to first convert the geotiff to a .vrt (virtual raster). This step takes essentially no time, as it just creates an XML file describing the key properties of the file. You then edit the .vrt file to change the palette to the one you want on output and add a look-up table to provide the mapping between input colors and output colors. With this done, you run gdal_translate again to generate a new geotiff with the new color palette. (It's actually easier than it looks written like that). gdal tools tend to work on very large rasters, so I suspect it is fully capable of processing the entire NLCD image in one shot. After that, you can skip right to the blurring step (presumably on an extracted tile), though I suppose it's possible that Photoshop might be able to handle the entire map as well.

If anyone is interested, I can provide more details on editing the .vrt file

Map Making Support / Re: Creating installer using Inno
« on: April 23, 2013, 03:59:31 PM »
You can't just go dragging files around, they must be converted.  ;)

The classic way is to use a Garmin antique called mapconverter: http://www8.garmin.com/support/download_details.jsp?id=3898

How about when you're creating a new mapset? How do I get from the outputs of cgpsmapper (*.img, .tdb) to gmap? The description of mapconverter suggests that it will convert installed maps. Do I have to install them first, just to create the gmap format? Is there a 3rd party tool that will assemble the pieces. I tried looking for such a thing, but nothing seemed to fit.

Map Making Support / Re: Creating installer using Inno
« on: April 23, 2013, 03:30:24 PM »
I was unfamiliar with the .gmap approach. To try it out, I took a mapset that was working via registry entries and moved the files (mapsetname.img, mapsetname.tdb, and *.img)  to ...AppData/Roaming/Garmin/Maps/<mapsetname>.gmap/
I removed the registry entries.
I fire up MapSource (6.16.3) and the maps don't appear on the list of available mapsets. I guess I don't understand what you're saying to do.

Nice idea to use gaussian blur in Photoshop.  :)  Whenever I used Photoshop to saveas TIFF, I needed to re-rectify, when I re-imported, because, although GM exported a geoTIFF, Photoshop stripped it of the reference data.  That was a long time ago.  Does it still do that?

As Boyd already noted, yes, Photoshop strips off the GeoTiff tags. In fact, almost every image editor will strip them off because they are viewed as non-standard tags so they are neither read nor re-written. Boyd has already explained how to address this in GM. For other tools that don't have this capability, you can use two programs from the GDAL package to save the header information and restore it. listgeo will read the tags and write them in ASCII to a file. geotifcp will read the tag file and insert the tags into a tiff file, making it a geotiff.

Map Making Support / Creating installer using Inno
« on: April 23, 2013, 08:12:16 AM »
In this thread - http://forums.gpsfiledepot.com/index.php/topic,2383.0.html (page 9), you provide a sample Inno script. I just want to make I understand this script. If I read the script correctly, you are forcing the user to install in the user's Garmin\maps directory. Also, I see no indication that you are writing the registry entries. Not a criticism, just a question.


Pages: 1 [2] 3