Latest Contributions by LanceCole

Alexander,‌ You will need to create a empty feature class or shapefile with the needed attributes and input these yourself.   Create a shapefile or feature class as points with empty Strike and Dip attribute numeric columns. Set the default values to 0 (zero) for these to fields. Set up the feature symbology and labeling as noted in the video for this new feature.  There will not be any points to start. Georeference the TIF of your map so you can use it in ArcGIS. Zoom to one of the Strike & Dip symbols on the map in ArcGIS. Drop a new strike & dip point at the location of the symbol on the map. Type in the Dip value for the point. Using the rotate tool rotate the point symbol to line up with the symbol on the map.  You can also manually input the rotation value and adjust to best fit using trial and error. Repeat for the next symbol. ... View more

@Alexander, It may have been less confusing if I had pasted the correct hyperlink for rotating point marker symbols.  See revised link in previous post.  My apologies Here is a video link to Plotting Dip and Strike Readings with ArcGIS.  You will need to create the feature class for your strike & dip symbols, add the points and input the data for strike and dip. ... View more

Alexander, When you create your strike and dip feature class you can set the Strike attribute to control or be populated by the rotation of the strike and dip symbol.  Please see  How To: Rotate point marker symbols in ArcMap. You can physically rotate the symbol to change the attribute or change the numeric value manually. I hope that helps. ... View more

Neal, For some reason your function was seeing the "dte" parameter as an integer.  Not knowing the entire setup of your model it is difficult to say why.  If you look at your error message you can see the date was being passed Calc(6/15/2019), not an integer.  By adding single or double quotes around the parameter "%Date%" it forces the parameter to a string.  You can then convert that to a date and perform the needed formatting.  I hope that helps as to the why. ... View more

Alexander, So by raw data you mean you only have a scanned or hard copy of the map?  No GIS digital data points, correct? As you know but for others, the strike is the orientation or rotation of the symbol on the map the dip is a number listed next to the symbol indicating the steepest angle of plunge.  On a map oriented with north up,  a strike and dip symbol oriented straight up and down the page, the strike would be 0 or 180 depending upon the side of the dip.  A strike dip symbol oriented straight across the page would be 90 or 270 depending upon the side of the dip if using azimuths.  I would recommend georeferencing your map into ArcGIS as you have coordinates for the corners.  Once georeferenced, add a strike and dip symbol for each point on the map then rotate the symbol to align to the symbol on the map.  You can also add the dip info as an attribute.  The orientation of the symbol can be extracted from the data and populated as an attribute.  Sorry but no automatic way to complete this but there are not that many points on the map you attached. Here a few links for georeferencing and symbol rotation:     Fundamentals of georeferencing a raster dataset     Rotating point feature symbols ... View more

Hi Alexander Do you have a sample of the data you are working with?  Unusual data would contain the dip without the strike.  I assume the data is in point format, is there a rotation value for the points that may correspond to the strike?   ... View more

1) can you please provide the link to the datasheet you are referencing.  I would like to use something you are actually utilizing to expand my reply. 2) if your surveyor has a survey grade GPS rover pole, have them shoot a series of points over an area that is readily  accessible.   I like the center of manhole covers because they are easy to find, big, do not move and can often be seen in imagery.  Shoot how ever many locations you would like to use as check points using averaging for a few minutes at each location.  Repeat on another day and average the results.  You now have a known set of points, in a known coordinate system that you can check your data transformations against. 3) the GNSS metadata that is stored with your collector data contains the latitude, longitude and altitude (height above the ellipsoid) in the coordinate system your GPS is running.  I use this data and project to coordinate system were are using.  I am really looking forward to Collector support for 3D points using our GPS.   ... View more

Oh the joys of data transformations. 1) you needed to lookup the data sheets for NGS Survey Control Monument you are using.  These will list the coordinate system and datum used for the published data.  They may be different depending when the monument was set and/or last verified. 2) make sure you are collecting the correct data using your equipment.  I am fortunate in that I have access to in-house survey control data specific for my location in a known coordinate system and datum.  Check with local surveyors, county map office for survey pin data on plats, state monument boxes for roadways, etc.  You only need a few points to cross check against.   3) selecting a transformation - I keep our collected data in the datum we work with for our GNSS, in our case NAD83 (2011).  I transform the control data to this system for verification.  This can be difficult but typically common sense prevails.  You know what system your data is utilizing and what system your control was collected with, what is the most logical path between those two. I prefer ArcGIS Desktop for the aspect of determining as you can load your data in and set the data frame coordinate system along with transformations for other systems. The transformations can readily be changed in Desktop whereas I have not found this functionality in Pro.  Once you have your data loaded in a MXD add your control data and play with different real-time transformation to see what works best.  In our case our control data is in NAD83(1987) but our collector works with NAD83(2011).  We found a combo transformation of NAD83(1987) to NAD83(HARN) to NAD83(2011) worked the best. 4) signs of a transformation issue     a) all your data is shifted the same distance and direction, within the accuracy of the data     b) a gradational shift such as data to the north is shifted NE, central data appears to be accurate and southern data appears to sifted to the SW.  Another example is data to the north appears accurate but as you look at data further to the south a larger shift is noted in some direction and increases the further south you go.     c) some pattern in the data differences 5) accuracy issues - if the differences between your data and the control points are random most likely you are not looking at a data shift but rather an accuracy issue.  You need to know the limits of your equipment and the control data.  Keep in mind if your equipment is rated accurate to 6 or 12 inches that is typically a plus or minus.  You need to double those values and not be looking for cm accuracy. ... View more

Alina, I am not going to be able to help much.  I have not had the opportunity to try the new z-enabled capability of Collector for ArcGIS (v19.0.1).  This is primarily supported with the Arrow/EOS receivers and software and we are using Leica receivers that, unfortunately, have not caught up yet.  Your workflow outline appears to be sound based upon my understanding. The main issue with data obtained from Collector is "What coordinate system is my data in?"  Going from a GPS receiver, running on various RTK systems, on different coordinate systems, that each manufacture integrates differently with Collector, pushing to AGOL, that uses base maps in one coordinate system but allows you to publish your features in another, back to ArcGIS Pro that does not clearly define which coordinate system it is currently working in, and the fact that there are hundreds of possible combinations of coordinate transformations, all to have your data not appear where you think it should be appearing, or is the data right and the map/image wrong.  No wonder it is confusing. One thing I can highly recommend is to create a set of control points.  I have two sets I use, one is a small number of points around the office neighborhood that I can quickly go for a walk, on a nice spring day, and test a new collector map.  The second is about 24 points over a large area that I can use to test at finer level that can catch things such as datum shifts that may not be visible on a small localized set of points. We collected these control points using a survey grade GPS, using the coordinate system we ultimately will be working with and typically using 5-10 minute averaging at each point.  The points have been collected at several different times and the results averaged.  I keep them in a shapefile or GDB feature class that is readily accessible. When I am working with a new Collector Map or trying to figure out is my new transformation workflow model working correctly, I go for a walk and collect these points.  Once collected I bring only the points into an ArcGIS session, perform my transformation workflow and then bring in my controls points to see how they compare.  Sometimes my collected data shows up in the middle of the Indian Ocean, other times it is a few feet off but most of the time it is within the accuracy of the GPS.  When it does not work I tweak my workflow and run it again, check my map or GPS configuration, recollect the points and check it again.  It is simple and quick and I am checking against a single absolute known. Working with multiple coordinate systems in you data is difficult.  We are in the process of migrating from NAD 83(86) to NAD 83(2011) the difference between the two systems can be 2+ feet.  The key here is to make sure you have the correct transformation assigned in ArcGIS between the two systems.  There is also a performance price to pay for working with multiple coordinate systems as some of your data needs to be projected on the fly.  This is most notable when it is your imagery that is being corrected. The best option is to work in a single system or as a second option work in your imagery coordinate system to minimize processing time.  Another option, if possible is to obtain a physical copy of the imagery, is to reproject the imagery to your preferred datum.  Just plan on some serious processing time depending upon the extent and image quality. Sorry I cannot specifically answer your question.  I hope this helps. ... View more

Correct, Collector does not work with vertical datums.  Additionally, the base map does not impact the raw data.  This is why you must use the raw data from your GPS that is stored in the Latitude, Longitude and Altitude attributes when points are collected to AGOL to create the 3D points and transform them to the coordinate system you ultimately need.  I believe these are store in the raw data format or configured data formate for all GPS units.  You may want to confirm this with Trimble, as we are using the Leica product line for our ArcGIS Collectors.  It is my understanding some GPS manufactures are providing full horizontal and vertical datum support but this is not via ArcGIS Collector but rather the apps provided by the GPS manufactures such as Arrow and EOS that integrate with collector. We we have our profile configured as shown below to work our State VRS system and post the data to AGOL as each point is collected in the field.  We work through the process we have been discussing to generate our survey points for internal use to the accuracy of the instrument. Our GPS receiver and State VRS are using GSC NAD 1983 2011 and we use the ESRI default for AGOL of WGS 1984 Web Mercator Auxiliary Sphere as our map coordinate system.  The transformation is the default Collector recommended for this paring. You may need to take a step back and insure you have your database configured, have added the GNSS enabled fields  and have it properly published to AGOL to be collecting the correct data.  This must be working before you can even think about performing the transformation on the data.  You also need to be sure your GPS software is also properly configured in conjunction with Collector.  I am not going to be much help with a Trimble unit, as noted above, we are using Leica.   Also, do you have RTK enabled and configured for your GPS.  This will substantially affect the performance of your R2 unit.  That sounded like something out of “Star Wars”. Sorry, I currently only have a few moments to respond but can provide additional information later this evening, if needed or you have more questions.  This was not an easy process so please do not feel you are not qualified.  There are just a ton of variables that all need to be inline for everything to work.  Once it is working, it is great. Small steps: 1) make sure your GPS is configured correctly and you are received the correct data, including RTK outside of Collector 2) make sure the GPS is correctly communicating with Collector. 3) is the correct data being posted to AGOL with the correct GNSS data 4) the data that is being returned back from AGOL is correct. 5) post processing is correct and using the correct transformations. ... View more

Randall, I looked into this a little further.  I found if I log onto Portal via the https://<Portal_server_FQDN>:7443/arcgis/home url, in our test sandbox deployment it is https://gisprt01.lgc.local:7443/argis/portal, all traffic is going through this path.  However, as soon as I go to the Status tab under Organization, it is using our web adapter alias for the path.  This is https://gis.lgc.local/portal on the test deployment.  This is resulting in the error shown as the path in the browser does not match the path being used.  The browser path is https://gisprt01.lgc.local:7443/arcgis/home/organization.html#status.  Go to another tab and it reverts back to the proper path.  So far, only fond this issue on the Organization > Status page on portal in both IE and Chrome. ... View more

Follow-up - I found if I clear the cache in IE and Chrome, the status page will load when using the FQDN of the web server hosting the web adapter.  https://<Webserver_FQDN>/<webadapter>/home but if I use the portal server https://<Portal_server_FQDN>:7443/arcgis/portaladmin or a pointer to an alias to the webserver https://<Alias_to_WebServer>/<webadapter>/home the status page will not load.  All other pages on the portal site appear to be working. ... View more