Shawn Billings, post: 420303, member: 6521 wrote: GIS software is still remarkably weak regarding geodesy as far as I know. Can GIS software handle time dependent transformations? Last I heard, no. But it could be different now.
No it cannot. But will that change over time be significant enough for the intended purpose of the GIS application? In most cases no. So unless that horizontal change is in the magnitude of meters, then it's likely insignificant. Also, did everything else on the map move in the same relative amount? Then again that is insignificant for the majority of the uses of GIS. No one SHOULD be using GIS for legal representation of property boundaries. Assessor GIS systems should be for approximate boundary location only, with the underlying parcel data being of primary importance.
Then we're back to the difference between GIS and surveying being accuracy, which is unfortunate as surveying could learn a thing or two about data management from GIS, but the measurement handling will need to come along, which is also true for CAD, truth be told. The difference being that CAD doesn't imply geographic competence in its name.
GIS is primarily about displaying and analyzing spatial data in ways that aren't possible with other systems. The underlying data is as accurate as it needs to be for the analysis being performed. If you want to election results for a certain polling place in an obscure district is rural Montana, it can do that. No need to have the location of the polling place to the centimeter.
But if you're analyzing sewer flow, you better have accurate data collected using sound surveying procedures. That's where metadata comes into play. Each layer should have how it was collected, its accuracy, and acceptable uses.
Survey data can be used in a GIS and should be in certain cases. But it's not necessary in most cases.
If anyone wasn't aware, I'm an Esri employee, working on our projection engine and somewhat how that library gets utilized in the various Esri software/applications.
I did a paper in grad school on whether I thought MapInfo met the published academic criteria of a GIS at the time (1993). Perhaps, thankfully, I've forgotten the full list.
Others have listed a several criteria but I'm going to list what I remember:
- display / visualization
- dbms-capability
- analysis
- data attribute manipulation
- editing
- macro / programming capability
I then dug out a book, Geographic Information Systems: An Introduction (2002) by Tor Berhardsen which listed:
- acquisition and verification
- compilation
- storage
- updating and changing
- management and exchange
- manipulation
- retrieval and presentation
- analysis and combination
The GIS can only be as good as the data that it has access to. Precision is there, and we work hard to maintain it and the data's accuracy.
Meanwhile, in the projection engine, we're actively working on the 15 parameter (sometimes called 14 parameter), time-based transformation. It's running locally in a test version, but needs further testing. I don't know when it will be exposed in the publicly available software. We (and EPSG) have put in the WGS84 realizations, although there are no transformations to convert between them yet. Nor have we tagged the existing DMA/NIMA/NGA transformations to a particular realizations. The transformations are so inaccurate, that it doesn't really matter which WGS84 realization is used. We're also working on vertical transformations. The Geoid12b and EGM2008 are supported plus VERTCON (for what it's worth!). Some other geoid models should be available soon.
Melita
Melita, as a heavy GIS user and Esri Partner, it's good to hear that Esri is continuing to improve its products in ways such as this. Thanks for informing us.
GIS = Get It Surveyed
[USER=7183]@mkennedy[/USER] I was hoping that you would chime in. I was aware that you are a geodesist and also work for ESRI, so I was hoping that you might correct any of my unintentional errors.
I do believe that GIS will be more relevant for surveyors once it is able to handle transformations better.
Considering that the lifespan of the database may be many decades, the precise positions need to be able to ride along for the various iterations of adjustments and realizations.
I recall that when I first started using GPS, surveyors and most of the developers for surveying software were unconcerned with WGS/NAD83 and treated them as functionally equivalent. Which for the purpose at the time, they were. Then when WAAS and other SBAS's were becoming prevalent and increasingly more accurate, the difference in the two was larger than the noise in the positions. GIS professionals probably regard most or all of their current data as being too noisy to require accurate transformations, but such thinking limits the expanded applicability of GIS, in my opinion.
Today, much of our software continues to treat WGS84 and NAD83 as equivalent. Some software deals with WGS84/NAD83 seven parameter transformations, which is better than nothing at all. Adding time dependent 14 parameter (I suppose the 15th is time itself? - i.e. epoch) transformations is even better, and some now do that. I'm only familiar with one commercial survey software that incorporates HTDP (allowing for regional time dependent transformations just like NGS), although I could well be wrong about that. Hopefully this approach will allow precise data to maintain its precision better through the passage of time.
The other question is that of metadata. Do GIS databases allow for measurement metadata on a point by point basis or is it thematic (relating to all points in a similar theme)?
I am glad that ESRI has people like you pushing for more purism in its geodetics.
Thanks, Shawn.
Let me first say--not a geodesist! I did get a master's from Ohio State's Department of Geodetic Science (before the big schism) but my focus was computer-aided mapping. Everyone had to take courses in the other concentrations so I got a smidgeon of surveying and geodesy, plus whatever I've picked up since.
My colleague, Kevin M. Kelly, a Canadian geodesist, and I were among others who asked NGS to provide some sort of transformations between HARN, NSRS2007 and 2011.
Part of the strength of GIS data formats (even the lowly shapefile) is that a feature can have multiple attributes/values associated with it. So you could have general metadata that's true for the entire dataset, and then geometry/feature-level metadata as well. We've been struggling a bit with the time-based transformations--do we assume that all data within a dataset has the same collection time? We may have a separate tool that can reconcile features to the same epoch, before they get sent through the 15-parameter transformation.
That's a great question. You can't really depend on the collection time to accurately reflect the epoch. The epoch will be determined by the correction source which may not be readily available, even to the field operator.
Blue Marble as far as I know is the only commercial software handling 15 parameters. No one in the industry is handling time dependent shifters that can feed CAD/ESRI systems and respond to the right shifts given time. Melita / Shawn - I don't think there is anything you can do at the dataset level for features fed from different correction sources. A feature level metadata that holds the transformation name used at time of loading is a solution (MXGPS is the only software that does this), but that instantly grows stale (non-dynamic). Metadata entered by humans is the only way. Melita - the first position time for a file (a base file Date/Time) would be adequate to "tag" a dataset for time dependency shift to kick in, don't you think? This second at GMT time is what is assumed for mapping grade products when fetching CORS data, and for surveyors submitting an OPUS solutions (I might be wrong on the latter).
If an OPUS held project is held and data tied to that OPUS position is entered into a GIS, then this gets tricky, since tagging a dataset to a datum tag requires a "PRJ" file from a library, or the unhappy consumer must fetch the PRJ and WAG it. This, in my opinion is the result of poor documentation and is not and intentional error, but a blunder on the part of the GIS person given too little information from a competent data source. It's a role for GIS to shift properly, but we need the right info.
Maybe this is where a great rift occurs between GIS and Surveyors who use OPUS or VRS/RTN and easily acquire a tie to the NSRF, while us in GIS have no OPUS without dual frequency and must tie to a "WGS84-NAD83" shifter at some quality level. We are guessing until 2022 comes along, or if we get 15 parameters, and are actually using a system that can "see" the difference. Love to say this, but OPUS rocks. Without that OPUS report, I'm not trusting a RTN RTK project without proper documentation (that comes from a human). Sorry.
I'm waiting for NGS to script this out for 2022 so we can handle this on this whole datum issue on-the-fly. Until then, I'm holding, like many real=time sources, a time of observation for a base station and HDTP to the NAD83(2011) EPOCH 2010.0. Professional GISers are not doing much things different than you guys/gals than getting corrections over your phone on the site. Just that our receivers are cheaper, and were throwing away vertical, and no, maybe a hundreth of a foot is not our concern. But were going to get there - soon.
Trimble mapping grade GIS users, if they were paying attention has been doing the right thing within 7 parameters since CORS has been feeding CORS user friendly format, the published NAD83 position at the epoch of choice at time of download. This has been the case since first generation of CORS96 (epoch superceded now by epoch 2010.0). Not here to pop any surveyors bubble, but GIS aware users using post-processed GPS systems have been aware of "WGS84/NAD83" since about 2001/2002 when SA was turned off and before the first WAAS enabled satellite was launched. We, GIS, took many of this issue to the streets, since high resolution GIS data, contracted with the Surveying community were recognizing disparity between coordinates collected in GPA and "GIS".. You, surveyors, brought us GIS folks to the table with a table set for us. Few recognized this in GIS, and some in Surveying were kinda late for the dinner too.
This was the epoch of "major shifts between GIS/Surveying". Now, as software catches up, and after enough videos are published by the like of Henning, Dennis books by Sickle were getting this down.
I rambled on. Sorry.
