Messages

I'm not a moderator or author on this site, but here is what is going on. The Java applet that is used to upload our maps to the server is "jumploader" - a Java applet that is not written by Oz. It is available for free here: http://jumploader.com/

The code for the applet is on this website (gpsfiledepot.com) - that's how it can run here. However, Java has a security feature built into it (which the jumploader applet is forced to encounter, since it is running on Java). The security feature is designed to warn us, the end users, if a Java applet is running on a site and Java can't verify that the applet is from that site.

The process of verification of the applet is 'certificate signing.' A website owner (i.e. Oz) purchases a trusted certificate key from a "Certificate Authority (CA)" and then uses that certificate to 'sign' the Java applet. Then, when we run the applet, Java can verify that the applet belongs to this website. Essentially the process of certificate signing adds a layer of security that makes tampering or hacking of the Java applet easier to detect.

Apparently Oz has not purchased a certificate. So we are getting a warning from the Java program that tells us that Java can't verify that the applet (jumploader) is signed by the website we're on (gpsfiledepot.com). Therefore, Java is trying to warn us that there is some risk that the applet isn't what we are expecting (it could have been hacked) - Java can't guarantee that what we're going to run (after clicking the 'accept the risk" button) is the absolute same applet that is associated with this website.

The security warning is NOT a warning that the applet has been hacked or that anything bad is going on. It is simply a warning that Java (the program) can't verify that the applet (jumploader) has been signed by the website we are on (gpsfiledepot.com).

Certificates are REALLY expensive.
http://www.digicert.com/code-signing/oracle-java.htm
http://www.godaddy.com/ssl/code-signing-certificate.aspx
https://www.thawte.com/code-signing/content-signing-certificates/sun-java/index.html

Recent updates to Java have increased the 'scariness' of the warnings that come when Java is 'asked' to run an unsigned applet. See here:
http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html

So, the bottom line is:
1) Oz could buy a certificate and make the scary warning go away.
2) I think it is unrealistic for Oz to buy a certificate. Too expensive, and the problem isn't worth the price of the cure (for me).
3) The worst case scenario would be:
a) Someone creates a Java applet that is bad
b) That person hacks into this website and uploads their bad applet in place of 'jumploader'
c) We run what we think is jumploader, but it is actually the bad applet, and it does something bad to our computer.

To me, the risk is minimal because: the chances that someone hacks into the website to upload a bogus applet is minimal, but even if that were to happen, the chance that the applet can do something bad to my computer is minimal. Applets run in a 'sandbox' - which is a protected place which does not have access to the rest of your computer's operating system. There have been holes in the Java sandbox, which viruses can exploit, but the holes are typically plugged very rapidly by browser or Java updates. So the risk is minimal <to me> because I:
1) run my computer with a firewall
2) run good antivirus software which is up-to-date
3) frequently update my operating system ("windows update") (once a month)
4) frequently update Java (once a month)
5) frequently back up my data (at least once a week) to an external drive that is physically disconnected from my computer when not actually getting backup data (because I unplug it after running the backup

Dave
The non-IT professional, who can't be sued when you do what I suggest and things go bad for you. If you're uncomfortable with something, don't do it. Also note that I don't say the risk is ZERO. So there is a risk you could blow up your computer, your TV, your refrigerator, and perhaps your garage door opener if something bad happens. Your move.

go to Control Panel then Java. There are a bunch of settings in there you could try changing (such as moving the security slider to medium). I can't see a setting that resets your previous answers to 'do you trust' types of questions.

what broswer / OS are you using? There is probably a java prompt setting that we can figure out to change to fix your broswer behavior

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?

Notwithstanding the previous comments regarding the use of GE imagery within KMZ files, which I agree is not appropriate, the comment / issue is still valid when dealing with creating KMZ files using any other image overlay.

Version 7 of GE introduced the 'feature' that when opening KMZ files, the view automatically tilts to a 45 degree angle. I'm not sure if that's what we're talking about here, but there are three work arounds:

1) Press the "R" key on your keyboard and the view resets to overhead and north up. Handy shortcut.

2) When creating the KMZ, use the snapshot feature. It will automatically create the code below in the KMZ file.

3) Include the following code inside the KML file within the KMZ file that you create:
<name>whatever</name>  ***i'm just including this so you can see where the LookAt tag goes
     <LookAt>
           <longitude>-72.99605633362627</longitude>  ***specify the center point of the view you want
           <latitude>42.54080694367089</latitude>
           <altitude>0</altitude>
           <heading>0</heading>
           <tilt>0</tilt>   ***this is the critical thing we're talking about here
           <range>7400</range>  ***this specifies the 'zoom' level
           <gx:altitudeMode>relativeToSeaFloor</gx:altitudeMode>
     </LookAt>
     <GroundOverlay>

In all of my KMZ files, I couldn't find a real good example of an image that went to 1 megapixel with one side not being 1024 pixels. This was the best I can find - the image is 700 * 1106, which is only 774,200 pixels. But it definitely proves that you are not constrained by 1024 pixels in either dimension of the image. I usually am just lazy and resize the images I am working with so that the long side of the image is 1024 pixels - then I know I am within the Garmin 1 megapixel limit.

http://www.gpsfiledepot.com/maps/view/629/

So, yes, you can do any combination of pixel dimensions as long as the overall pixels are less than 1,048,576 pixels (which is 1 megapixel, 1024^2). So your example of 666 * 1500 would work, but you are leaving some pixels on the table - you could do 699 * 1500 and it would also work.

I use mapc2mapc for producing tiled KMZ maps.

Instead of restating it here, see also my discussion on the resolution of tiles for KMZ maps:
http://forums.groundspeak.com/GC/index.php?showtopic=307548


Dave

This site offers almost infinite customization to do something like you're looking for:

http://www.mappingsupport.com/p/gmap4.html

This is from about 3/4 of the way down the "examples" page:

"Gmap4 map displaying georeferenced photos"

"If you use a KML file instead of a GPX file then you can add photos to your map. The Gmap4 'Help' file walks you though the process and gives you KML template files to get you started."
http://www.mappingsupport.com/p/gmap4.php?q=http://www.mappingsupport.com/p/gmap4/helpfile/Stafford_Creek.kml&t=t4

You will need a place to upload your GPX or KML file, since the Gmap4 website doesn't host your data. I am now using dropbox to host my KML and KMZ files for use with the Gmap4 interface. For example:
http://www.mappingsupport.com/p/gmap4.php?q=https://dl.dropboxusercontent.com/u/78581604/maps/svt.kml

Dave

OK, I'll bite....what happens if you exceed the segment limit? Pestilence, war, famine, and death?

Does the segment limit only apply to the 'active' maps being displayed, or all the maps loaded onto the unit (regardless of if they are 'active' or not)?

Is the segment limit the same for all models or does each model have a different limit?

Not sure if this is the right forum category...

On a whim, I decided to try and pull up my Google Maps version of some of my KMZ maps on an iPhone 5...and it worked! I hadn't thought about it before, since I'm not an iPhone user. Who said KMZ files were only for Garmin lovers?

If anyone has an Android powered phone, can they try the links and see if they work?

See here:
http://www.gpsfiledepot.com/maps/view/651

For more technical details on my exploration of Google Maps compatibility with KMZ files:
http://forums.gpsfiledepot.com/index.php/topic,3197.0.html

[workaround for Google Maps limitation on 3 Mb KMZ files]

I continue my quest to become an expert KMZ file maker...but with all the IMG map creation expertise around here, I feel like becoming an expert at KMZ files is kind of like hanging out at a party of math PhD's and saying "yeah, but I'm REALLY GOOD at addition!"

Anyway....

1) workaround for Google Maps limitation on 3 Mb KMZ files: Since we (those of us creating KMZ files for Garmin GPSr) already have to use some kind of tool (I use MAPC2MAPC) to accommodate the Garmin limit of 1 Mb, we are halfway to the solution:
a) after creating the multiple tile KMZ file for the Garmin KMZ, create multiple smaller KMZ files with the right number of tiles to keep each KMZ file less than 3 Mb. (I have found that the best performance is actually with KMZ files less than 1.5 Mb). This is really easy to do if you have one KML file (from within your 'master' KMZ) that references all the tiles. You just use that KML as the basis for all of the KML files in the smaller KMZ files - just delete the references to the tiles not being used in each KML file associated with the multiple smaller KMZ files. Essentially you're building the multiple smaller KMZ files with a text editor to manually edit the KML files, and manually compiling the smaller KMZ files with a ZIP file editor.
b) Create a KML file with "network link" attributes that can be read by Google Maps.

This is all easier to understand with an example. See my "Middlesex Fells" KMZ here:
http://www.gpsfiledepot.com/maps/view/579/

The KML that is used to generate the Google Maps 'preview' is here:
http://www.dbperry.net/maps/fells.kml
You can download it and open it up in a text editor to inspect the syntax. Basically it is calling 10 separate KMZ files which 'tile' together to create the full map.
Unfortunately, the Google server 'reading' / 'loading' of KMZ files seems slightly unstable - sometimes you have to 'refresh' your browser a few times before all the tiles will load in.

2) The same "network link" attribute in a KML file can be used to display overlapping KMZ files. See this example:
https://maps.google.com/maps?f=q&hl=en&q=http://www.dbperry.net/maps/nw_fram.kml
(which are the maps in my Northwest Framingham "Bay Circuit "E to K" KMZ Series:"
http://www.gpsfiledepot.com/maps/view/607/

It even uses the draw priority of each KMZ to display the KMZ files in the correct / intended overlap!

3) There is a workaround to simulate transparency for KMZ maps in Google Maps. KMZ files support the GIF file format, and the GIF file format supports transparency. So you can:
a) convert your JPEG map to a GIF
b) replace the 'background' color of the GIF with 'transparent' pixels. Photoshop Elements or Photoshop can do this.
c) Create a KMZ file with the GIF file as the image.
d) When you load that KMZ file into Google Maps, it is "semi-transparent"

I tried this and it is pretty cool, but I didn't save my example, because...

I have abandoned this approach because Garmin does NOT support KMZ files made with GIF files. Garmin only supports JPEG. So I am going to focus my efforts on KMZ files that are compatible with the Garmin GPSr, which is my real reason for creating KMZ files. Too much extra work just to get transparency in Google Maps (although it does make the Google Maps KMZ implementation much more usable).

4) Finally, last, but certainly not least, I found the Gmap4 website, which (among other things) uses the Google Maps API to display KMZ files on all kinds of maps. For example:
http://www.mappingsupport.com/p/gmap4.php?q=http://www.dbperry.net/maps/nw_fram.kml

Notice the menu in the upper right corner - you can choose 13 different 'foundation' maps as the background!

Lots of neat features on the Gmap4 website: http://www.mappingsupport.com/p/gmap4.html

My next project will be to create an interactive, hot-linkable Gmap4 map with all of my KMZ maps. In other words, a big (small scale) view of New England with all of my KMZ maps displayed. Clicking on each KMZ map will bring you to the correct GPSFileDepot page where you will be able to download the Garmin compatible KMZ.

Fun stuff!

Hmmm, that sounds odd. If you follow the instructions linked in my post above, the JPG picture file should be within the KMZ file - not 'downloaded as a link.' There is no way you could have a 275 KB picture inside a 1 KB KMZ file. Not sure how to help...

Sent you a PM.

If your KMZ file is truly 1 KB, I'm guessing it doesn't have the JPG inside it. Are you following the instructions on this page?
http://www.garmin.com/us/products/onthetrail/custommaps#fragment-2

Garmin GPSr will only read KMZ files with JPG 'tiles' that are smaller than 1 MB. Is your KMZ actually 1 MB (1024 KB)?

Dave

acdsee is great photo management software and allows editing of any exif fields.

http://www.acdsee.com

sorry, it's not free, but acdsee 15 will do what you want.

I would imagine there are free exif editors around, but I don't have any knowledge on that.

Dave

I've discovered a similar, if not identical issue with my KMZ creations. See these two maps:
http://www.gpsfiledepot.com/maps/view/680
http://www.gpsfiledepot.com/maps/view/575

One is a simple inset that overlays on the other. As with all KMZ files, they only 'appear' when you zoom in close enough to see them. For example, when the scale bar is at 3 miles, the small scale (large area) KMZ disappears, but at 2 miles or larger scale, the small scale KMZ appears.

So I created the two KMZ with the intention of having them both appear at the same time - it would be cool to get the high resolution of the large scale and the greater area coverage of the small scale KMZ at the same time. I specified the proper 'drawpriority' (which is called "Draw Order" in KML / KMZ / Google Earth) to get this to work - a lower draw order for the small scale and a higher draw order for the large scale. But a funny thing happened - when both of them are loaded on my GPSr, the large scale KMZ will not appear until you zoom in to the 120 foot scale bar. But if the large scale KMZ is loaded on the GPSr by itself, it is visible at the 0.8 mile zoom! I tried all different combinations of settings on the GPSr - I even changed the draw order to make the two KMZ have a greater 'difference' in draw order between them. No change. I'm open to suggestions, but I doubt a solution exists. Not sure it's a 'bug' - this might be far enough beyond the usual usage of KMZ files that the Garmin firmware isn't up to the task.

Oh, to be able to individually select KMZ files to activate on the GPSr! We can dream...

BTW, I'm using a Garmin GPSMAP 78sc for this silly fooling around.

Dave

i don't know about the turn-by-turn functionality, but these are routable:

http://garmin.openstreetmap.nl/

Dave