Jump to content

snowfleurys

Members
  • Posts

    494
  • Joined

  • Last visited

Everything posted by snowfleurys

  1. GM does not relate all the GNIS types to an mp_type. You need to write a conversion as you did for the NHD codes (as you included). Since you do not have a conversion for all the GNIS type, I assume you chose not to include them or that no feature with that code existed in your area(AZ). Note: the code you used for cemetery (0x1a) is for a polygon feature, the point cemetery code is 0x6403. Since 0x1a is not listed in the cgpsmapper manual as a point code, cgpsmapper may need a type file to define it. Unknown feature types should not be a problem. Using USGS 1:24000 SDTS DLG data and GM defaults, I did not have any problem with cgpsmapper (version 9.02? from last fall) creating .img files with thousands of unknown points, lines and areas. After finding out what these were, I deleted many of them (and redifined others to GM types) before creating the .mp files.
  2. Add Going to the Sun highway in Glacier National Park. On the east side it is shown as a prominent red line, on the west side as a minor thin grey line (and that is when zoomed in). I know it is seasonal, but it used to be the paved through road across the park.
  3. Take a look at their statusmaps. You appear to be good for WA, OR and ID. NV,UT,AZ,NM,NE,KY,TN,NJ, and NY also appear to be complete. The statusmap is dated May, 2005, so the other states may or may not be complete. The soil data will be mostly contiguous polygons; somewhat like the digital geologic maps you can get from USGS for most of the states that I hope to be able to add to the GPSr.
  4. Not a CA guy and only looked at the info on the wr6.com site, but it states that 100K data was used for roads/trails (therefore, at most highway names) and hydro. Also 'missing ... most labels, boundaries and manmade structures', so probably little if any use was made of GNIS data. The CA guys will have to decide if the 20ft contours are worth it. My 2 cents is it probably does not match your first Colorado version. Thanks again for your hard work.
  5. I understand. Nice to know that using political boundaries would cause more problems. I would expect some users to not like having to download an entire adjacent state, but you need to do what works and is easiest for you. This is a huge undertaking. Again, thanks. My current thinking is to include them as intermittent streams. They do add some information (where they exist) that is lost by contouring a grid (expecially where much of the 10m data is actually resampled 30m data). My initial attempt to include the geology (esentially contiguous polygons) worked, but caused some other data issues.
  6. IndyJpr, I noticed that the latest Colorado data seems to end at -109W - the border with Utah is actually a few miles west. This is common for western states. It appears you included '46007' ephemeral crenulated streams. Many/most have sections of '46003' intermittent streams between them and the '46006' perennial streams. On zooming out, this leaves them unattached. These watercources are not on the USGS 1:24,000 maps and water is in them far less often than the intermittent streams. This was an addition by the Forest Servicee for areas within forests. I have not decided what to do with them (code as intermittent, make a new type, or not use at all). See the Sept, 2007 issue of the NHD newsletter for a discussion. -- OZ you might also want to check this out -- On my 76CSx, I find that the land status green makes it harder to see the other features. How do others find it? Does seem faster, especially in panning from home location to another area. Thanks IndyJpr.
  7. Nice work IndyJpr, Utah has some good transportation data. Did you notice that most of the 4-wheel drive trails in the Moab area are labeled? Hope to have a chance to check some of those out next month.
  8. Oz, Can not help you on your method. What I did this weekend was to put 60 100K files in a folder. Then used 'file / open all files in a directory tree'. Then 'export vector data / export shapefile'; once for to area, then to line, then to point. If you only wanted the data from the flowline files you could do 'tool / control center' and delete all the non-flowline files. A lot of work as their are 11 files (if I remember correctly) per 100K quad. Mark
  9. I used the following referencehttp://nhd.usgs.gov/NHDinGEO_FCodes_by_layer.pdf to decode the ftype/fcode from the shapefile. I don't have my laptap booted yet - where my notes are - but from the top of my head the waterbody mapped pretty well: glacier lake, wetlands... For area I believe I mapped almost everything (paths, canals, connectors, etc.) to small streams... The Fcodes have intermittent versus pernial information. I have a dBase file I can send you, but have no idea how to do so with the computer I am now at, at the public library. I try to do it first thing tomorrow.
  10. Love your contours. Howerver, and IndyJpr could verify this as I have only been looking at a 1 degree square in Colorado, my '.img' contour lines files are about 1/8 the size of the '.mp' files. That would make your 414mb '.mp' file about a 50m '.img' file. With about 60 square degrees in Arizona, you would have about 6Gb of '.img' files. IndyJpr could probably say if an 50mb '.img' is too big for cgpsmapper. The early version of GM9 was set to use the previous simplification evey though the slider bar was showing 0.5 when you entered that screen.
  11. Love your contours. Howerver, and IndyJpr could verify this as I have only been looking at a 1 degree square in Colorado, my '.img' contour lines files are about 1/8 the size of the '.mp' files. That would make your 430mb '.mp' file about a 50m '.img' file. With about 60 square degrees in Arizona, you would have about 6Gb of '.img' files. IndyJpr could probably say if an 50mb '.img' is too big for cgpsmapper. The early version of GM9 was set to use the previous simplification evey though the slider bar was showing 0.5 when you entered that screen.
  12. quote name='Marky' post='3337945' date='Feb 25 2008, 07:42 AM']Show me where the name is in this email response from the system:
  13. The name of the quad or subbasin was in the notification email - in Nov, 2007.
  14. Wow, It never let me do more than 2 at time - would just hang after I pressed download. And never more than half the 160kbs of the DSL. With each file now exposed for twice as long, if seamless burped, both files would have to be restared.
  15. Hi Oz, Well since Utah is my first application of the high res data I'm still doing some testing. Fortunately - for Utah - there seems to be an extra attribute, "IsMajor", which roughly distinguishes between perennial and intermittent streams... I'm not sure what I'll do on the other states... IndyJpr, There is a data type field in NHD (actually two, and general word and a more specific number field). Beaware than some feature types occur as more than just one of point, line, polygon depending on how it was shown on the original 24K. Waterfalls on a single line stream are points, on an area stream they are lines. Rapids can be points, lines, or areas (a series of rapids on a wide stream). Same for dams. Reservoirs, streams, canals, bridges, and levees are also in two catagories. I have an idea of how to handle these, but you and others might differ.
  16. Is that 10 minutes for the entire quad (all 4? chunks) or is that for one chunk? If indeed for the entire quad than that is a nice connection you have (and the seamless server must be lightly loaded)... You guys are going to have the NED done really fast. I didn't want to scare you off before but the NED downloading is the easier of the two.... The NHD (water) data is downloaded by an irregular area (subbasin) so there isn't an easy way to go through the chunks - pretty much have to do some screen prints and mark off the ones you have downloaded. And the process is asynchronous - you pick the chunks and the server says thanks - we'll get back to you..... They do get back to you, sometimes in 5 minutes, sometimes in a couple of hours and sometimes in days... The GOOD NEWS is that there is a lot less data - it'll be 100's of MB for the water data versus multiple GB of elevation data. I'll post the instructions for the water data this weekend. Thanks, Not quite sure how to get this down to the just the appropriate part of the original so I'll leave it all in as this might be helpful for your NHD efforts. This will be based on my experiences in Oct/Nov, 2007. NHD is obtainable by 100K quad. I found it by accident while seeing what the data looked like and then took about an hour to find it again. On the NHD-viewer (nhdgeo.usgs.gov) zoom into your area of interest (about half the size of Colorado). On the right side open up base map features. Scroll down to 100K Quad Index. If this does not appear - you need to zoom in more. Check the box and circle. On left side scroll down. Note that How to Extract now appears - I had to ask them as it never occured to me that such critical info would be initially hidden. Click on polygon extract. With the mouse, make a small box inside the quad you want. Map redraws with selection in blue. Extract window opens - actually before redraw. Top shows info on what is selected. Under 1 - select High Resolution (the default is 1:100,000). Under 2 - select shapefile. Leave 3 unselected. Enter your email address in 4. Select extract. You may or may not get an interim email. The final email will have a hotlink to download the data. Other info (as how is was in 2007) Yes, more than one quad/basin can be selected - however, the data will all be in one file and the time seemed to go up much more than the individual file sizes would indicate. Available bandwidth to process was usually more on the weekend - the system is in active use/updating by Federal and State agencies during normal working hours. The system does go down and seamed to lock-up more if there were large numbers or requests in the que. Someone at NHD on a work day, needs to realize this and reset the system. Your requests may or may not be lost. It was quite common for me to find on Monday morning that small requests at numerous times over the weekend would have continous request numbers with only one or two missing. ** IndyJpr please take note ** The data returned will be the FULL feature for everything within or crossing the selected boundary. Waterbodies, areas, flowlines, and lines will not be split at the boundary. Therefore, you will have duplicate features. I would suggest IndyJpr tests how to remove these dupicates, as I remember reading cgpsmapper errors-out if duplicate features are in an mp file. Also - at the 100K scale many quad names occur more than once (ie Springfield 4 times). The download files produced last fall would include the data for all similiar named quads - and sometimes take days to put together (decreasing the resources available to process other requests). This was especially bad if the quad file name included 'of', as in Craters of the Moon and overedge quads as 'North of ....' There all in one file. Just a few things to be aware of.
  17. The quads I have downloaded from seamless take about 15-20 minutes when at my DSL max of 160k/s Most of the time its been more like 110-140k/s, or about 20-30 minutes per 'quad' (droped to barely 90 about an hour ago). Seen it as slow as 9, or not even working for days at a time (hardward problems/changes, etc). Then there are the times with 10's of minutes in the extractor stage, building archieve, or waiting for extractor. I've even experienced the number of requests BEFORE me waiting for a extractor INCREASE by 30-40. Many times it has taken 4-5 or even 6 hours to download 2 or 3 files. Marky, you have had remarkable sucess. My download rate is now down in the 70's.
  18. Hydrography problems - data from CDOT was used. There metadata states 'dataset copied' in 2004. No infomation on source, source scale, processing, etc. is given. Since NHD at 1:24,000 scale was only completed a few months ago, with only a few basins available in 2005, I doubt if CDOT used anything better than 1:100,000 scale data.
  19. The view in mapsource is greatly improved. Have not had a chance to load the revised version to the GPSr. Just got my first data onto the GPSr. USGS SDTS DLG via GlobalMapper 8.03 to mp file via cgpsmapper (freeware) to imp file via sendmap20(freeware) to Garmin 76csx What software/procedure did you use to create the files needed for viewing/selecting in mapsource? Thanks, Mark
×
×
  • Create New...