Land management overlay may be translated slightly north and to the west

Brian's Avatar


22 Aug, 2019 11:01 PM

My caltopo map:
County GIS map:

I was recently using caltopo to plot out some different points of interest in an area where I am about to purchase land. The land management overlay was of particular interest to me because we may like to request an easement from the NFS. I plotted my land by pulling the coordindates from the county gis website. By doing this I am confident that the satellite imagery is correct. I then used the satellite imagery to plot out an abandoned mining road so I can describe to the NFS what portions of their land I wish to use. However, when comparing the NFS overlay on caltopo to the NFS overlay on the county GIS website, both with a base layer of satellite imagery, it becomes clear that one of the mapping resources is wrong. I've added four reference points to my caltopo map linked above for trouble shooting purposes. The road reference point appears correctly to be in the road in the satellite imagery in both caltopo and The 3 NFS boundary reference points are the coordinates of nearby NFS boundary corners pulled from the website. These are clearly offset from the land management overlay nfs border by similar amounts and directions. My guess is this is a bug in translation or datum or something like that. Maybe the map has changed over time. In any case, I'm curious to know if this is a known issue, if it might be fixed ever, or if you believe it is not a bug. Please feel free to reach out for any clarifications.

  1. 1 Posted by Brian on 23 Aug, 2019 01:44 PM

    Brian's Avatar

    Upon more consideration, I no longer believe that the Land management layer is shifted or translated in some direction. Rather, I wonder if it's possible that the Land management overlay is drawn using some kind of vector graphics and those vector graphics are simply less precise than the ones I'm seeing in the county gis software. Could that be?

  2. Support Staff 2 Posted by Ben Lantow on 23 Aug, 2019 11:43 PM

    Ben Lantow's Avatar

    I've sent this over to our developers, it looks like you're right. Either a datum draw issue, a vector draw issue, or some issue with the underlying data we are using does appear to offset this slightly. I don't know which it is but be assured we are looking into it.

    I would default to Summit's GIS for the time being and I'll work to get you a solution early next week, we definitely want our data to be reliable and accurate.

  3. Support Staff 3 Posted by matt on 26 Aug, 2019 11:27 PM

    matt's Avatar

    I don't think this is anything in the CalTopo rendering stack (datum, projection, or line simplification), but probably just an issue in the underlying dataset. If you turn on the FSTopo 2013 layer, you'll see that the nearby mining claims are rendered more-or-less the same between the land management and FSTopo 2013 layers, but the town is shifted. If this were an error on our side and not in the source dataset, I'd expect the errors to be more systemic (and if it's a simplification bug or other issue drawing vector data, the mining claims are the ones that should get mangled the most).

    The land management layer comes from BLM's surface management agency dataset. I would definitely defer to the county GIS server (and plat maps, if available) as being the definitive source, and if you have any doubts, the local USFS office would probably be happy to put you in touch with a USFS GIS person who would be happy to confirm for you what they think their forest boundaries are.

    My best guess would be that the town's boundaries came from a different dataset than the mining claims, and that dataset was imported into the BLM's master dataset with the wrong datum.

  4. System closed this discussion on 02 Oct, 2019 04:25 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac