POST
|
We created an Quick Project for ArcPad 10, and it is using a VB script to pull the gps.z value I am assuming from the NMEA string (GPGGA) from the GPS unit. The GPS set up is a survey grade leica unit that passes the NMEA string to a Trimble NOMAD 800 via a serial cable. The NOMAD GPS has ArcPad 10 installed on it. Examining the NMEA string from the Leica unit, I can see where the altitude is outputted from the unit along with height of geoid (in meters). The antennea height on the Leica GPS unit is set to 2m or ~6.56 ft. In the ArcPad Quick Project, the map's coordinate system is set to State Plane Florida West (US Feet). The GPS protocol is set to NMEA 0183, Port COM1, Baud 4800, Antennea height 0 (US Ft), Geoid Seperation 0 (US ft). The option to use map units (feet) for height is checked. There is a custom form created in the project for certain features where the collector can change the value of the antennea height and use the map units as default (which is feet). The default for this field is zero. Here is the vb code specific for that feature type: Dim AntHeight, ObjHeight Dim tmpPage1 Set tmpPage1 = ThisEvent.Object.Pages("page1") If ThisEvent.Object.Mode = 3 Then ThisEvent.Object.Fields("Collection").value = Now ThisEvent.Object.Fields("COLDATE").value = Now End If If GPS.IsOpen Then AntHeight = CInt(tmpPage1.Controls.Item("txtAntenna").value) ObjHeight = Abs(AntHeight - GPS.Z) ThisEvent.Object.Fields("ElementZ").value = ObjHeight End If When the values come outof ArcPad10 in shapefile format, we run a simple script to correct the elevations against a geoid difference grid, and when these are compared to known bench marks, the elevations are consistently 5 ft higher. I know it is not the script correcting for the geoid difference as it is the same grid and mathematical calculations used in the project version for Arcpad7 run on a PDA and using the same Leica GPS unit to feed the NMEA string to the PDA. (The PDA elevations come in within a few tenths). I know that it is not the Leica Unit which is feeding the NMEA string to the NOMAD GPS unit because it feeds the string correctly to the PDA. It is also not a field collection issue. Can someone give me an idea as to what might be causing the calculation error? Below is a sample NMEA string from the leica unit and a known bench mark elevation. Sample NMEA String: $GPGGA, 141444.80, 2813.4106465, N, 08243.2780716, W, 4, 07, 1.3, 10.718, M, -25.348, M, 0.02, 0001*7D Known Bench Mark Elevation: 37.3471 The only way I can get close within 0.4' of this known elevation is if I take the Altitude 10.718 and subtract it from the Geoid Height (-25.348) then convert this from meters to feet (36.066*3.28) and subtract -2' (which adds 2). (This value is supposed to be 2 m or ~6' as the specified antennea height from the gps unit but if I subtract 6' the elevations are ~ 9' higher). Then obtaining the geoid difference grid value (83.40384) for this xy coordinate (converted from meters to feet) and then subtracting the two values (83.40384-120.2965), I get an elevation of 36.89 which is a difference of ~0.42'. Can someone explain what values ArcPad may be looking at from the NMEA string to calculate the elevation? I suspect that my mathematical procedure of using the altitude and geoid height may not be the right way to calculate the elevation, but it is the only way that I have found to get close to the known benchmark elevation. Also, does anyone know what ArcPad might be interpreting to get a 5' offset (where the final elevations are higher than the known benchmark data)? Are there any known issues with ArcPad 10 and calculating elevations from the NMEA stream? Any help would be greatly appreciated! Thanks, Kathy
... View more
12-27-2011
06:15 AM
|
0
|
0
|
461
|
POST
|
For ArcGIS 10 SP2 (using the ArcInfo license and Spatial Analyst extension), I am attempting to use the join field tool between a shapefile and a file geodatabase feature class. However, the script is performing erratically where it works for some machines adding the field and values while other times it only calculates the field with one value (in the screen capture below refer to ElementZ_1) when it should be multiple values as it is correcting the ElementZ value. It is using the x coordinate field as the joining field. The script is below. It is a pretty straight forward script. The original data is coming from an ArcPAD generated shapefile. Are there any known issues with the join field tool or any ideas as to what can be causing this issue? Thanks for your help. Regards, Kathy
# Import arcpy module
import arcpy
from arcpy import env
# Overwrite pre-existing files
arcpy.env.overwriteOutput = True
# Check out any necessary licenses
arcpy.CheckOutExtension("spatial")
Input_point_features = arcpy.GetParameterAsText(0) #Feature Class
Correction_Field = arcpy.GetParameterAsText(1)
# Local variables:
Input_Raster = "C:\\WorkingFolder\\ArcPad_PascoCo\\Geoid_Correction_2011\\pasco_geoid\\pasco_geoid"
Points_With_Geoid_Elev = "C:\\WorkingFolder\\ArcPad_PascoCo\\Geoid_Correction_2011\\pasco_geoid1\\kathyz.shp"
Interpolate_values_at_the_point_locations = "false"
Field_Name = Correction_Field
Expression_Type = "PYTHON"
Field_Type = "DOUBLE"
Expression = "(!ElementZ!-(!RASTERVALU! * 3.280839))"
Output_Feature_Class = Points_With_Geoid_Elev
Data_type = ""
Input_Join_Field = "ElementX"
Output_Join_Field = "ElementX"
Join_Fields = Correction_Field
Delete_succeeded = Points_With_Geoid_Elev
# Process: Extract Values to Points
arcpy.gp.ExtractValuesToPoints_sa(Input_point_features,Input_Raster , Points_With_Geoid_Elev, "NONE", "VALUE_ONLY")
# Process: Add Field
arcpy.AddField_management(Points_With_Geoid_Elev, Correction_Field, Field_Type, "", "", "", "", "NON_NULLABLE", "NON_REQUIRED", "")
# Process: Calculate Field
arcpy.CalculateField_management(Output_Feature_Class, Field_Name, Expression, Expression_Type, "")
# Process: Join
arcpy.JoinField_management(Input_point_features, Input_Join_Field, Points_With_Geoid_Elev, Output_Join_Field, Join_Fields)
# Process: Delete
arcpy.Delete_management(Points_With_Geoid_Elev, "")
... View more
09-18-2011
02:23 PM
|
0
|
0
|
1002
|
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:24 AM
|