oisact
-
Posts
77 -
Joined
-
Last visited
Posts posted by oisact
-
-
Random thought: Doppler shift changes the carrier frequency at the receiver. I wonder how that will affect carrier phase measurements.
It shouldn't. Regardless of if the received frequency, the transmission frequency is known, and the EMR still travels at the same speed. So you just count pluses and multiply by by the transmission frequency instead of the received frequency. Also, the receiver should know what the doppler shift will be at any given time (based on the GPSr's last known location), just like it knows where the satellites are in the sky. Receivers (especially the very sensitive ones) most likely have to account for doppler shift already, especially since they are operating at gigahertz frequences.
Dan
-
I tried setting the draw order (see this post), but that didn't have any affect.
Here's a screenshot with the proper rendering within my own custom maps. I changed the polygon bitmap to something solid (I just set the transparent color to green, and made the existing green a bit brighter).
If I could just get it rendering properly relative to roads I'll have it made. Oh, some higher res land cover data would be nice too. I determine that its not that the land cover is out of alignment, but it simply isn't that precise. The raster GeoTIFF is pretty low resolution, so an individual pixel covers a pretty large area.
Dan
-
Okay, in GPS Map Edit I opened the .MP, went to Map Properties, then Extras tab, and added a property for DrawPriority. First I tried level 20, since 25 is the default. That did indeed fix the problem as far as my custom maps were concerned. The land cover now draws under all my custom maps, so it no longer occludes rivers. However, the land cover still draws over roads. So I tried level 1 and level 0, and the problem persisted.
The MetroGuide maps must not be transparent. I created a non-transparent map with DrawPriority 1 and it was not visible.
As far as I can tell, my only recourse is to modify the MetroGuide maps so they are not transparent. However that would probably allow the base map to show through, resulting in some duplicate roads. A solution would be to create an entire map for the USA that is not transparent but blank, that can be used behind the MetroGuide maps.
Any thoughts on this? I wonder how this guy did it? VTrader, with your shaded elevation maps, have you addressed this problem yet?
Dan
-
Thanks. I originally downloaded cGPSMapper from the official site, but the zip only included the EXE and nothing else.
Do you know what the draw priority is for the Garmin maps? Specifically the MetroGuide map. Also, is the MetroGuide map transparent? Or does it cover the base map? If it isn't transparent then it won't be possible for me to fix the issue with land cover overlapping some roads.
Dan
-
I read somewhere that exposing an eTrex to high temperature, like on the dash of a car, will cause the adhesive to break down and the rubber to come loose.
Dan
-
The satellite generates and transmits a random sequence, and the GPSr generates the same sequence at the same time. The two devices are synchronized to time (the sat via an atomic clock, the GPSr in turn synchronized to the satellites).
The data sequence the the GPSr receives lags behind the sequence it generates internally, due to the fact that even at the speed of light there is still a measurable delay, which represents how far the GPSr is from the satellite. Currently consumer GPSr receivers measure that delay going by the data stream, which is sent at around 1 MHz. That gives an accuracy of around 1 microsecond. They use some additional tricks to increase that accuracy. The carrier signal is 1.5 GHz. If the GPSr can count the time delay difference in cycles of the carrier it will allow nanosecond accuracy, leading to centimeter accuracy in position.
Dan
-
I'm no expert, but my interpretation is this:
The satellite encodes data on (modulates) a radio wave. The radio wave is transmitted continuously, and the GPSr locks onto it and observes it for changes, which represents the encoded data. So if a high data bit needs to be sent, a property of the wave is modified accordingly. Because the data rate is much slower than the frequency of the radio wave the GPSr will receive many cycles representing a specific bit of data, so it has a (relatively) long time to detect the change. The faster it can register the change, the more in-synch it will be with the satellite, and thus the more accurate it will be. If the GPSr could monitor individual cycles, and detect the exact waveform cycle that the data bit was first applied, then the precision could lead to centimeter accuracy.
This would probably require some real-time post-processing, like recording thousands of cycles, and then analyzing them to see the exact cycle the modulation was changed. A thousand cycles only takes 1.5 microseconds (a millionth of a second), so it would of course seem real-time to the end user.
Dan
-
Yeah, I thought it was silly having a completely different model, with a different name and color, just so they could stick a CD and Micro SD card in the box.
Dan
-
It's like with hard drives. Lower capacity is actually more expensive because they don't make them anymore (or make less of them). There's always a magic spot in the supply / demand curve as technology progresses, sort of like surfing a wave. Stay in that and you'll get the best prices. Go for cutting edge or try to fix up legacy hardware, and the costs are higher.
So in other words, Garmin saves money by utilizing a 128 MB card instead of 64 MB (sorry, in case you thought they were just being generous
).Dan
-
There are four measurements with two pieces of hardware:
Odometer:
gpsmap 60 csx 11,6km
etrex vista hcx 8,36km
Save track information on the gps unit:
gpsmap 60 csx 11.83 km
etrex vista hcx 11.27 km
The fact that the Vista's odometer and its own track log vary that much shows that it has a major internal descrepency. When you consider that three of the four measurements are in agreement, then it is very likely that the Vista's odometer is wrong.
Dan
-
They should all work fine. Your GPSr will consume less amperage than what any of those power supplies produce, but that's okay (the power supply should be capable of more amperage than the device will consume).
Dan
-
I tried setting the draw order for the woods polys (0x50) to the lowest level, but as you predicted, that does not affect the draw order between maps. There must be some way of determining which map gets drawn first - I doubt that is completely random.
Your suggestion of merging in the other maps would work - but only for the maps I have control over. The issue with the woods covering interstates and other non-line roads would still exist. Also, I like having the elevation contours, hydrology and land cover as separate maps, so I can select which I want to view on the GPSr itself.
One workaround for now is that I changed the bitmap for woods polys to be something mostly transparent. That works pretty well, as these screenshots show:
Another potential solution is to make the land cover map opaque - but that would only work if I could be certain it is rendered first in place of the default yellow background. However, if I could make it render first, then that would solve the problem anyway.
Dan
-
If you are the type of person that likes convenience, the preloaded SD card would be nice. You pop it in and use it. However if you like customization and expandability, then you're better off buying a big blank 2 gig card and the PC software, so you can put more on it, including custom maps.
I went the latter route.
Dan
-
Here are some screenshots. While taking these I noticed another problem. The land cover is being drawn at too high of a layer - it is covering my hydrology map, and its covering some roads too, like interstates that have thickness to them. Also, as I mentioned above, the land is slightly north of where it should be. These are displaying my custom hydrology, elevation contours and now land cover maps, as well as MetroGuide North America 7.
Trees should follow south edge of river, not overlap it:
Day color screen of same area:
Same area without land cover map. Note how much more detailed the river is - it has thickness.
1:24k USGS topo of same area:
So, any suggestions on changing the draw order between my custom maps?
Dan
-
Okay, I've got at least a county's worth of land cover on my GPS now, and I'm pretty pleased with the results. Currently the GPSr is rendering the wooded areas like trees - sort of like random sized irregular circles. I don't know if I like that - it looses a bit of detail, and its hard to tell exactly where the edges of the wooded areas are. Also, regardless of the zoom level, the trees are always rendered at the same scale, which I don't really like. So I'll probably see about rendering those polys solid, or maybe with a custom texture (if you can render predefined area types in a custom way - I might have to change them to a custom area type).
The demo version of Vextractor has a limit of 30,000 elements when saving (if I remember the number correctly). By extremely good luck, when I vectorized and saved an entire county, Vextractor first saved the wooded polys, then was in the process of saving the hydro polys when it hit the limit. So it actually saved me work by not exporting the other area types I didn't want.
I've figured out a pretty fast method of removing the polys I don't want in Global Mapper. There are two colors I wanted to keep - green and dark green. The color values for those are 6728299 and 3368476. So first I found each of those colors, then modified those polys to have the Wooded Area type. Then I did a search for elements NOT having the "Wooded Area" type (!=), and deleted those. So it was basically three manual steps to cull it down (which removed the water marks too).
The resulting IMG file was only 749k.
Dan
-
How far are the coordinates off for you? I overlaid my land cover onto the 1:100k USGS topo map in Global Mapper, and it is extremely close. If anything, the custom map might be slightly too high - like by 1 pixel worth in the original TIFF file.
Dan
-
I checked again, and all the color values are 0 for me. So I vectorized the TIFF again and now I see the color values. So somewhere in my manual editing of the MIF I messed those up.
My one concern at this point is when I remove some of the polygons, sometimes there are other polygons behind them. For example, I may remove some road, and underneath it is woods. That is just a side affect of the vectorization process - it probably makes the filesize smaller to overlap polys in certain cases. Hopefully there are some settings in Vextractor to take care of that.
I have a couple techniques for removing the watermarking, so I'm good there.
I haven't reached the maximum filesize yet that the demo version supports. Hopefully it's pretty big.
Thanks!
Dan
-
I'm not exactly sure what you mean by "manually edit the MIF", have you tried editing in GlobalMapper (GM)with the search feature? You can search for a particular type, then select all, and edit them as a batch.
Editing the MIF file in a text editor like Notepad.
I tried the search function, and if that would work then I would have it made. It seems there aren't any unique attributes it can use. For every single item it says "<UNNAMED FEATURE>", "Unknown Area Type", and 0 for color.
Dan
-
I hoped GPSMapEdit might work. However, the MIF file Vextractor produces uses "Nonearth" coordinates, which GPSMapEdit won't import. Global Mapper loads the file fine (except for the colors / area types).
I think it's time for some screenshots.
Original exported land cover GeoTIFF:
Vectorized by Vextractor (better quality is possible, but will result in more polys):
1:100k USGS map for comparison:
After loading into GlobalMapper:
My plan is to remove most all area types, like water, roads, populated areas, etc, leaving mainly vegetation.
Dan
-
Very nice. That sort of reminds me of this shaded-relief.
I've done some testing, and it is possible to achieve some very good results with the land cover. I compared a USGS 100k topo map to the vectorized land cover, and the quality is very close.
I'm currently stuck trying to bind colors in the vectorized MIF file to area types. I can load the MIF file in GlobalMapper, but the colors are all off, and no areas are defined a type. One possibility is for me to manually edit the MIF file so it only contains one type of area at a time, load that in GlobalMapper, and then assign it a type. Of course that would be very tedious.
I had GlobalMapper export a MIF / MID pair, to see how it encodes areas. That is defined in the MID file. However when I reopen the MIF back in GlobalMapper it doesn't display anything. That's not very encouraging that GlobalMapper cannot properly read back a file it has just written.
Redwoods, thanks for the links. I tried both those applications and didn't have any success with them reading the MIF file. Neither would display anything.
Dan
Edit: changed 24k to 100k
-
GC IDs are pretty short. When he goes to enter the ID, does he first delete the existing, default waypoint ID? I know the number of characters varies between different GPSr devices, and it is very unlikely that you can configure something like that. It would be hardcoded into the firmware.
Dan
-
I found the problem. Hopefully this will save someone else some trouble.
When a map is compiled it produces two IMG files. One is a Preview file (Prev.img) and the other is the actual map with all the information. The prev.img file is usually very small. In the registry where custom maps are specified for MapSource, it was pointing directly to the actual map IMG, not the preview IMG. So the result was that the map would display as it should, but could not be selected.
I messed up when manually editing the .REG file that enters the custom map information.
Dan
-
Many people who use their GPSr in the car want it to come on automatically when the car is running, just like any other device in the car (radio, etc). If it stayed on when the external power was removed then it would require an extra step to turn the GPSr off manually every time you leave the car. That of course would result in a lot of dead batteries.
I don't know how much your unit differs from my Venture Cx, but I have an option under Settings->System that specifies what to do when external power is lost. Default is "Turn Off", which first provides the 30 second warning you see. The other option is "Stay On", which might be what you want (reverting to battery power).
Dan
-
Thanks. That lets me rule that out.
Dan
).
Memory Question?
in GPS technology and devices
Posted
I don't know the exact amount, but I can assure you that 24MB is not even remotely close to storing all the maps.
It is possible to fit it all on a 1 GB card (1000 MB) - that is if your GPSr supports storage cards.
Dan