What I am now trying to figure out is how exact the contour interval can be. Will changing it for each 7 1/2 quad which is different (see my Colorado test of concept mapset) be too confusing for the average user? In my local area, I find having a 10' next to 40' somewhat 'disturbing/???', and I have seen 5' next to 40'. What to do with a dual contour interval on the source topo quadrangle - where the highly sloping area has the 'base' CI and the flat areas on the same quad are described with a supplemental CI. There are also many quads in metric. Perhaps I am too concered, as the vast majority of users could not tell much about landform detailed lrom the contour lines anyway.
Quote from: maps4gps on August 20, 2009, 01:46:30 PM
What I am now trying to figure out is how exact the contour interval can be. Will changing it for each 7 1/2 quad which is different (see my Colorado test of concept mapset) be too confusing for the average user? In my local area, I find having a 10' next to 40' somewhat 'disturbing/???', and I have seen 5' next to 40'. What to do with a dual contour interval on the source topo quadrangle - where the highly sloping area has the 'base' CI and the flat areas on the same quad are described with a supplemental CI. There are also many quads in metric. Perhaps I am too concered, as the vast majority of users could not tell much about landform detailed lrom the contour lines anyway.
Having one next with one CI next to another CI that matches USGS TOPO's shouldn't be a problem if your goal is to match quad CI's. Adding supplemental contours to select areas takes a bit more work. You have to run the contours twice (at both CI's) and then mask out and crop data from both, and then combine the two sets to make a composite contour set. See Lez's post on cropping shapefiles for free tools to achieve this:
http://forums.gpsfiledepot.com/index.php/topic,366.msg2671.html#msg2671
QuoteHaving one next with one CI next to another CI that matches USGS TOPO's shouldn't be a problem if your goal is to match quad CI's.
That is how my CO toc mapset is. Question is does the 'average' user find it of value.
QuoteAdding supplemental contours to select areas takes a bit more work
Much more and most of it is interactive/hands on for each quad.
QuoteYou have to run the contours twice (at both CI's) and then mask out and crop data from both, and then combine the two sets to make a composite contour set.
That would be the procedure.
Would the majority of users even care how close the map contours were to the original?
I remember one poster finding the 40' CI in AZ was too many lines for his purposes versus 4 or 5 posters prefered 20' where the source used 40'.
The term '24K quality contours' has been used to describe some mapsets. How is this defined?
I would think it would be by using the contour line data in the USGS SDTS hyposography file. Because of the density of the points describing the lines, this would be much large than any current mapset, perhaps even an order of magnitude. The lines could be thinned, but is the result still '24k quality'? What would be done in areas where this data is not available?
Would the CI change to metric where the source used metric units? For the best match/detail - yes. I would find such a data set too confusing to use. We accept it in printed maps because we have no choice. A GPSr mapset is different. Where is the best compromise?
I would guess that the average user wouldn't download and go through the trouble of learning how to install that mapset. Mac users are out in the cold in any case, witch roughly comes in at about 10%. Just my opinion.
Have you received any feedback on that mapset? I think if it were me, I'd make a PC installer, and convert a Mac version and actively seek feedback.
I have some mapsets that have meter next to feet and it isn't a problem. MapSourse, RoadTrip and the user's GPS will convert one to the other, and the contour lines work well with the printed map. When you move to a different style quad, you can easily change the units in the GPS to match the printed quad to match up the number format.
There isn't a beet all, end all map that can be produced, and fit everyone's use. As far as 24k/25K sets being all the rage, they don't work well with limited memory, such as with a Venture HC or older 8MB units. That's the battle between coverage and detail.
QuoteI would guess that the average user wouldn't download and go through the trouble of learning how to install that mapset.
I asked OZ and he said go ahead and make state maps for the central and eastern states. A day or so after I uploaded the first one, he added did the PC installer and graphic, then added the Mac version. Then continued doing so as I uploaded the other states. I asked him about OR and CA - he did not say no, but did not say yes either. I then redid the AR topo as USGS replaced the NED data for the entire state, the WV overlay contour using the USGS 3m grid from LIDAR data, CO with contour interval matching the printed 7 1/2 quads, and a PA topo/plan - plan where an older NED production method was used and the resulting contours do not match those on the printed topos. He did not do anything with the WV overlay, CO toc, or PA t/p mapsets and I never asked him to as they were somewhat one of a kind 'test of concept' mapsets.
QuoteJust my opinion.
Greatly appreciated. Thanks.
QuoteHave you received any feedback on that mapset? I think if it were me, I'd make a PC installer, and convert a Mac version and actively seek feedback.
One comment within a few days on the CO mapset asking if more detailed boundaries for Forest Service lands could be used which would show the private inholdings. Nothing about the CI and nothing on the WV nor PA mapsets. Specifically asked for comments in the CO & PA mapsets. I expect the users do not read much of the info provided - with that in mind, I never uploaded the AK mapset because of issues with ocean/island polygons (no comments on that issue when asked on the forums). I have asked for feedback on the forums on some issues, usually do not get any - but at times my level of concern is fairly deep for even mapauthors.
QuoteI have some mapsets that have meter next to feet and it isn't a problem.
I would not expect it to be for you, but for others, me included, it might be a minor issue.
Quoteyou can easily change the units in the GPS to match the printed quad to match up the number format.
I have never tired that. In a current project, the land elevations are in feet and the ocean in meters in the name field. When GlobalMapper makes the .mp files it converts the meter values to their value in feet. - would be nice if there was a way to make GM leave ones data alone.
QuoteThere isn't a beet all, end all map that can be produced, and fit everyone's use.
I agree. Where in the spectrum of use/needs is the best balance point? I and some posters find it hard to see hydro and contours when a land ownership/use polygon is used; for others it is critical; in my CO toc mapset I tried a compromise.
Quote... 24k/25K sets ... they don't work well with limited memory, such as with a Venture HC or older 8MB units. That's the battle between coverage and detail.
I was refering more to the overcontouring (20 versus 40 or 80) than 24k itself. I used a variable quad size in my state mapsetes to keep the average file/tile size to around 1.1Mb. Also no special typ file. Capabilities of older versus newest units, what to design for? With software for many units now supporting 4Gb, but still a 2025 file limit, 2+-Mb might be a better choice for an average file size. Oz once mentioned he prefers 8-10Mb files for his own use to somewhat balance all those 100+k files he also uses. I am considering a type file with a dashed contour line to be used in areas where the NED data does match the printed contours.
Also a blue dashed line for intermittent streams. I do not know what effect this will have on older units which do not support custom feature types, but how long should these enhancements be kept from newer units that do?
On some 'presentation methods', one person comments that s/he would like to see it a little different, but there have been thousands of downloads. Did the others like it and not comment, did not like it and did not comment, or not even use it? Should it be changed and risk x number of people then not liking it? I am open to suggestions as GPSr mapauthoring has it own unique set of limitations and parameters compared to the standards used on printed topo maps.
As far as mixing Metric and Stature on the same maptile, I don't think it's allowed, so there has to be a compromise. Here I would select feet for making the maptile, and under Units on the GPS, select Meters for Depth. This should display feet for elevation and meters for depth just like the printed map. I generally build out to a smaller target, whether the user has a GPSMAP60CSx or GPSMAP496, the intended use and target GPS dictates how the mapset is built.
For a public release, if people are downloading it and not commenting, then then they are most likely satisfied enough with the results to not bother with providing any feedback. I don't think that over contouring provides any value when using a printed map other that pre/post planning. In the field, my eyes generally fill in the contours better that the GPS. But then again, that's me, and I would say that I'm not the typical user by any means so my comments may be of no use.
Thanks. There has been 226 downloads of CO, 264 of PA, and 94 of the WV detailed overlay contour mapsets. OZ did not think the topo/plan would be very acceptable, so I never did MD/DC, VA or SC. OZ and I never discussed the CO mapset as IndyJpr already had one available and I would only do some or all of the central and eastern states. As home state, CO was done to test some concepts.
That mapset has mostly land contours with very general bathymetry - the printed source contours were in feet and these were converted to metric for the digitized version ; bathy in meters was added from some other source. Its been a long time since I looked at some of those options; CO is far from the ocean and large lakes.
I am not a typical user either, but if a tweek or small change makes it usefull to I lot more users, I will at least give it some consideration.
CO looks great. Go ahead with PA & WV if you have the time. I should learn how to create an installer. I thought OZ had a tutorial on how, but I do not see it - perhaps he just had some info in a post a year ago.
QuoteHow did you get the contour intervals for CO?
The old fashion way - one at a time.
Last spring I found a commerical mapping site (name ???) which for each 100K listed the 24Ks; a click on a 24K would give data on date, CI, etc without having to dowload each quad. About a month later that company was purchased by another company which kept part of the interface, but not the part to view the date, CI, etc. An hour or two for three or four days with one hand clicking on quads and the other writing the info on a USGS CO index map was not too bad. If all 8 in a row were the same, just wirte the data for one of the edge quads and run aa arrowed line across the other 7 quads.
Thanks. I do not often look at that series of tutorials because I learned using GM a few months before OZ made those.
Where does the 'release_version_1.00' folder go, root c: or under some other folder?
I'll give it a try when the 'normal' day starts. I am somewhat reluctent to download and use new software as sometimes it causes problems and takes forever to completely remove, and you can easily get so much of it. Thanks.
Seems I also need to read more closely. How to make a setup is mentioned in that tutorial's description.
Quote from: maps4gps on August 23, 2009, 01:13:56 PM
CO looks great. Go ahead with PA & WV if you have the time. I should learn how to create an installer. I thought OZ had a tutorial on how, but I do not see it - perhaps he just had some info in a post a year ago.
QuoteHow did you get the contour intervals for CO?
The old fashion way - one at a time.
Last spring I found a commerical mapping site (name ???) which for each 100K listed the 24Ks; a click on a 24K would give data on date, CI, etc without having to dowload each quad. About a month later that company was purchased by another company which kept part of the interface, but not the part to view the date, CI, etc. An hour or two for three or four days with one hand clicking on quads and the other writing the info on a USGS CO index map was not too bad. If all 8 in a row were the same, just wirte the data for one of the edge quads and run aa arrowed line across the other 7 quads.
For some reason I didn't see any new posts on this thread in time to work on it over the weekend, will get to the other two ASAP. Too bad the site with the info changed hands and cut the links, it woould have been a time saver. I did it the `ol fashioned way for a 100K CA set, really dreading doing that on a 24K set ::)
I'll forward you the NSIS scripts I used so you'll have them for future use.
QuoteFor some reason I didn't see any new posts on this thread
I have also noticed that on a few posts the past 2 weeks.
If you need info on the 100Ks, I started a dBase file on those when USGS began publishing them. Still a few unknowns, even after checking on the USGS MapStore website.
I have all the 100K CI's complete for CA QUADS, but it looks like I'm going to have to spend time on CalSil to get the 24K ones.
The NSIS script I use for installers is available here: http://www.gpsfiledepot.com/tutorials/how-to-create-garmin-topo-maps---part-9---compiling-data/
I use both the indyjpr and the mti map for Colorado. On the mti map I see 10' contours around my house, but dont recall seeing anything besides 40' contours anywhere in the mountains where i'm using topo maps. Around the .2 zoom both maps are usually identical. Zoom to 1 mile and the contours are the same the only thing I notice is that blue lines indicating creeks near head waters are more detailed on the mti map, making it a little more appealing to look at.
ON my Garmin vista gps the most detailed contours i get is 200'. I dont think i can change that.
Road info is very different on the two maps. Mti shows a lot more forest roads, unfortunately most have been closed. The roads on the indyjpr are mostly open. When out hiking i prefer the mti map because the closed roads can be a good reference point. When trying to figure out how to drive somewhere i use the indy map.
I really like having the blm land on the mti map, its not accurate enough to rely on but gives me a clue there is blm land around. Within national forest land I have found land ownership to be more accurate on the indy map. So that gives me a problem when out hiking, i want the more detailed roads info on the mti map and the more accurate land status on the indy map. If i'm in the car with the laptop i find myself toggling between the two maps quite often.
Hospitals are randomly placed across the mti map, no big deal unless you where actually looking for a hospital. Some other landmarks are repeated several times in a general locality.
All in all there both great maps.
Carl
For some items IndyJrp & I used different sources and/or processed/presented the data differently.
I created 40' contours in the mountains because thats what the printed USGS topos used.
QuoteON my Garmin vista gps the most detailed contours i get is 200'
Not sure what you mean here as the 10' or 40', etc should show when you are zoomed in to the 800' bar scale setting when using the mti mapset. 200' sounds like the intermediate index contour for an area using 40'
For roads, I used Dec, 2008 Census data; IndyJpr used CDOT info - the metadata indicating it was many years old - and some areas used 'internal codes' rather than actual street names. FS has some nice road/trail data; however it would be very time consuming too edit out the other road/trail data where both exist, or confusing to have both as their positions are usually slightly different.
I used the federal lands info from USGS and substituded more detail info from the Park Service.
IndyJpr may have use info from BLM. I since found more detailed info from BLM, however most polygons are not named in this file.
Point data is mostly from the USGS GNIS (geographic names information system). A lot of the coordinates in that file are not very accurate. Do you mean the hospitals are some hundreds of feet off, or that there is none at that location?
We both used NHD for hydro, however USGS is still changing that database so downloads at different times will have slightly different data. IndyJpr may not have included the 'crenulated ephemeral streams' on Forest Service lands as these are not shown on the printed USGS topo quads.
Quote from: maps4gps on August 25, 2009, 11:09:12 AM
Not sure what you mean here as the 10' or 40', etc should show when you are zoomed in to the 800' bar scale setting when using the mti mapset. 200' sounds like the intermediate index contour for an area using 40'
oh yea thats right, i guess i never zoom in that much
QuoteFor roads, I used Dec, 2008 Census data; IndyJpr used CDOT info - the metadata indicating it was many years old - and some areas used 'internal codes' rather than actual street names. FS has some nice road/trail data; however it would be very time consuming too edit out the other road/trail data where both exist, or confusing to have both as their positions are usually slightly different.
somehow it seems indy's map let the f.s. info over ride the cdot. Its pretty much the same as my most recent paper f.s. maps, only listing the open non gated roads. Yours shows tons more roads, great many of them closed or gated off
Quote
I used the federal lands info from USGS and substituded more detail info from the Park Service.
IndyJpr may have use info from BLM. I since found more detailed info from BLM, however most polygons are not named in this file.
within f.s boundries indy's maps the boundries seem identical to blm digital info i get at geocommunicator, so maybe thats it. That info is the most accurate i can find on land ownership. Thats strange though because indy's map sometimes shows blm and i think state school land as f.s. land. But outside f.s boundries i dont think it shows any blm land.
Quote
Point data is mostly from the USGS GNIS (geographic names information system). A lot of the coordinates in that file are not very accurate. Do you mean the hospitals are some hundreds of feet off, or that there is none at that location?
no hospital around, just randomly shown out in the middle of nowhere.
Quote
We both used NHD for hydro, however USGS is still changing that database so downloads at different times will have slightly different data. IndyJpr may not have included the 'crenulated ephemeral streams' on Forest Service lands as these are not shown on the printed USGS topo quads.
both maps have the same info when i zoom in enough (.2 or .3 miles). Zoom out to 1 mile and your map still shows the info and indy's doesnt, the streams look a little chopped up
edit: fixed quotes
Never mind what i said about hospitals. I was looking at heliports, big yellow circle with an H inside. All the hospitals have one and they are named for the hospital they are sitting on, the yellow circle covers up the small black square that marks the hospital so they appeared to be hospitals. Should have looked a little closer when i started seeing them every where.
I did find some mountain terrain with 20' contour intervals, that looks real good. I didnt find where it transitioned from 40' to 20', that could be confusing. I tried to make my own map following the tutorial from this site. Everything seemed to go good except i was never able to compile it all to make a map. I remember at some point downloading the dems i had to choose contour intervals, and i choose 20'. Maybe that could be one of my problems trying to make 20' intervals off of 40' interval quads?
As far as CI on the gps unit. I find the screen on mine too small to recognize geographic features at the 800' zoom, i'm usually looking for peaks and they always seem to be off the screen at 800'. If i could get 40' intervals at .3 zoom that might be good, hard to guess if it would be too much clutter on the screen.
I've been taking a closer look at the land ownership on Indy's map and its very accurate. forest service, state school land and blm land all appear with green background. If you scroll over the area the land is identified. State school land show up as state park, blm is identified as national park, and forest service names the national forest. The boundries are right for the blm and state trust land though. Its not clearly marked where the two different types of land meet. And hopefully most people know that state trust land generally isnt open to the public and its not a park.
Carl
Quote from: Carl.h on August 31, 2009, 03:08:49 PM
Never mind what i said about hospitals. I was looking at heliports, big yellow circle with an H inside. All the hospitals have one and they are named for the hospital they are sitting on, the yellow circle covers up the small black square that marks the hospital so they appeared to be hospitals. Should have looked a little closer when i started seeing them every where.
Carl
Oh right, we had something a while back about that... Here's the thread:
http://forums.gpsfiledepot.com/index.php/topic,422.msg3036.html#msg3036
My first map in Jan, 2008 used a CI of 20ft for Colorado. The contour lines at the non-40ft intervals will simply be placed somewhere between the 40' lines (and not add any resolution to the land surface being depicted) which have a more accurate position. A possible problem with 'overcontouring' is that everything will be about double and may overload the software and/or machine capablilty. I have been contouring using a 15' or less quad sizes.
Tests using a 30' quad size took a lot more time and some crashed due to lack of memory.
Try changing the detail level to 'most'. Everything should then show at the 0.3mi bar scale level.
There is a very limited selection of polygon colors (and land ownership catagories) available on the Garmin GPSrs. I do not recall any having a bounding line in a different color - the color just ends, and if the adjacent polygon uses the same color it is trial-and-error to locate the boundary. I used 'tundra' for BLM lands, but in Alaska, tundra exists, so I had to use 'green' for all (except military) ownership. Some have made custom type styles/colors; however not all GPSrs support its use, and I do not recall anyone mentioning what happens when a non-supporting GPSr tries to display/use a mapset with custom type styles.