|
POST
|
Hi, I'm sorry that I didn't reply earlier. Note: Pro is different; will explain below after ArcMap info. ArcMap will reproject all layers that have coordinate systems that aren't the same as the data frame's. What it won't do is the geographic/datum transformation part if there are no transformations already set. Let me show the workflow. GCS = geographic coordinate system (datum); PCS = projected coordinate system Data frame in PCS2 based on GCS2 Layer in PCS1 based on GCS1 PCS1 is unprojected to GCS1 GCS1 is transformed to GCS2 (if transformation is set, otherwise it's internally redefined to GCS2) GCS2 is projected to PCS2 If a layer is in GCS1 already, then just steps 2 and 3 occur. To check on whether there are transformations set, Open the data frame properties (right click Layers, then select Properties) Click the Coordinate System tab Click the Transformations button In the top box is the unique GCS in the layers and data frame Below that is the data frame's GCS At bottom is a pull-down that may show the name of a transformation or "None". Select a GCS in the top box, then check the pull-down to see if a transformation is set or not. We show a sorted list based on extent and accuracy, but it can be fooled by having a world base map, etc How much data can be off depends on the two GCS involved. Two newer GCS like WGS84 and ETRS89 should agree within a meter or so (or better). British National Grid uses OSGB 1936 so it will differ by more like a hundred meters from ETRS89 or WGS84. Pro: Uses a lookup table to automatically set the geographic transformations. The lookup table usually uses the most generic transformations available which sometimes are not the best transformation for a particular area. Just as in ArcMap, you can open the properties of a map and change the transformation. Melita
... View more
11-21-2016
10:03 AM
|
0
|
0
|
1867
|
|
POST
|
It's a parameter peculiar to this map projection algorithm--IGAC_Plano_Cartesiano. It's used for large scale data, generally a city. In a sense it's a scale factor, adjusting the horizontal coordinates based on the height of the city. It reduces the overall distortion, because the projection plane is located close to the GCS/ellipsoid surface. Adding in the height above that surface moves the plane to the local average elevation, so distances, etc. are closer to true. EPSG has the same definitions, but calls the projection "Colombia urban". Neither EPSG nor Esri have a predefined definition for Buenaventura. Unless it was added very recently, PROJ.4 doesn't support this projection. Melita
... View more
11-21-2016
09:49 AM
|
1
|
0
|
963
|
|
POST
|
Hi Simon, As you know, the Lo grids use positive south and west axes. We don't support those yet, everything is east-north (in that order as well). A workaround is to change the scale factor parameter in the definition to -1. That will flip the axes so you can use the data with the base maps, etc. Melita
... View more
11-09-2016
02:29 PM
|
1
|
3
|
3828
|
|
POST
|
No, but I do need to put that on my to-do list. We've missed ArcGIS 10.5 and Pro 1.4, but I may be able to get it into 10.5.1 / 1.5 (next year). Melita
... View more
11-08-2016
10:19 AM
|
0
|
0
|
3731
|
|
POST
|
Side note: the Batch Project tool has been problematic in the past, so I'm glad it's working for you. You can also right-click the Project Tool and get a batch version of it. I don't know why you're getting the same (good) results whether or not you set a transformation in the Batch Project tool. It could be picking up the transformation from the an internal active list of transformations (GeoTransformation Operation Set). We don't set any transformations in ArcMap, you need to set it to match the Project tool, as you've found. Melita
... View more
10-29-2016
06:59 AM
|
0
|
1
|
1382
|
|
BLOG
|
A customer had some questions on why Esri has "null" or "bookkeeping" transformations as well as why there are transformations which have the same parameter values, but convert between multiple geographic coordinate systems. Here's what I wrote off the top of my head. WGS84 is actually not accessible to normal consumers because it’s a military system. Yes, GPS reports WGS84, but in a degraded state. RTK/post-processing are actually linking to ITRFxx or local GCS/datum like NAD83 (2011). A lot of data is labeled NAD83 but is really another realization like NAD83 HARN or CORS96 or worse, a mix of several realizations as the dataset has been edited over the years. Similarly, there’s tons of data that’s labeled WGS84 that really isn’t. Some states had one HARN realization, other had 2 or 3. NGS only published conversions between NAD83 (1986) and the first HARN realization, not the later ones. Transformations didn’t exist between HARN, NSRS2007, and 2011 until a few years ago. We’ve put in transformations for GEOCON and GEOCON11 v1.0. There’s a new NGS version in beta that further differentiates between the various HARN realizations, by calling later ones FBN. The NGS CORS website has published some 14 parameter transformations (time-based coordinate frame which has 3 translations, 3 rotations, plus a scale difference plus 7 more parameters that have time components) between ITRFxx or IGSxx (basically equivalent) to NAD83 (realization). Esri has incorporated these as 7 parameter coordinate frames by dropping the time components. That means the transformations occur at the ‘reference epoch.’ Knowing there’s a mish-mash of data out there, I’ve put equivalents where I duplicate an ITRF-to-NAD83 with WGS84-to-NAD83 versions. I’ve also added null or “bookkeeping” transformations (where the parameters are zeroes) to get between GeoCRS (geographic coordinate reference systems) where there’s no other transformation or at a certain accuracy level, these can be considered equal. I have not been consistent about it, and have been putting in fewer as time goes on and I learn more about geodesy and as the accuracy has been improving on the more recent realizations. EPSG (http://www.epsg.org and http://www.epsg-registry.org) plan to put in the multiple realizations of WGS84 and Canada’s NAD83 CSRS shortly. We’ll follow, probably for 10.5.1. That’ll make everything even more confusing!
... View more
10-19-2016
03:53 PM
|
4
|
1
|
2064
|
|
POST
|
I checked on these bug numbers again. All three have both been marked as-designed (two in July 2016 and the other about a year ago) with this statement in the 2nd one: "The ECW sdk has been updated, to take the projection information in the dataset and use that. This was not being done in 10.2. Hence the prj file is not used but instead the projection info in the dataset is given precedence. This is as designed." By SDK, I assume that they mean the code that handles ECW as a raster type. So if there was a discrepancy between the internal coordinate system/georeferencing information versus the external (prj file and world file?) that could be where the offsets are coming from. If you have ECW and you're sure this isn't the problem, contact techsupport again, reference the bug numbers and say you think there's a different problem. Melita
... View more
10-19-2016
03:45 PM
|
1
|
0
|
2068
|
|
POST
|
Thank you! I've pretty much finished adding entries for 10.5, so I wouldn't be able to incorporate them even if I got them tomorrow. Next release (not scheduled yet but rumored will probably be in Q1 2017). Melita
... View more
09-22-2016
03:17 PM
|
0
|
0
|
1509
|
|
POST
|
The production of NTv2 files for the latter re-adjustments are all province-based. You would need to contact them to see if they have anything.
... View more
09-21-2016
12:03 PM
|
1
|
2
|
3731
|
|
POST
|
If I ran across "GPS Vector Components method" before, I didn't remember it. When I did a quick search for references, I'm finding that it refers to adjusting (post-processing) a set of GPS observations or measurements, not to converting between two geographic coordinate reference systems or datums. Melita
... View more
09-19-2016
01:35 PM
|
2
|
0
|
1279
|
|
POST
|
Hmmm, I'm not enough of a surveyor/geodesist to fully interpret and understand what they're saying. I found similar information in a book by Ron K. Adler, https://books.google.com/books?id=dJECrHJRkUsC&pg=PA73&lpg=PA73&dq=ijbd+datum&source=bl&ots=aN2qDW0Z_p&sig=MJkBguTTKCojhINUpp4pFyH7Ukc&hl=en&sa=X&ved=0ahUKEwjQ3Jzjl5zPAhUI_WMKHeI-CFkQ6AEIIjAB#v=onepage&q=ijbd%20datum&f=false To me, it looks like it was WGS84 more or less. The fact that they say "broadcast ephemeris" implies there was no post-processing. They didn't recalculate the results using the precise orbits. Checking around, I'm finding accuracy (error?) estimates of 1-3 meters for broadcast ephemeris data. See this thesis for example: http://www.colorado.edu/ASEN/asen6090/broadcast_vs_precise.pdf If you can get decent imagery and identify the pillars, that's probably all you need. Melita
... View more
09-19-2016
12:59 PM
|
1
|
0
|
3439
|
|
POST
|
Hi, I'm sorry that I didn't see your question sooner. No, you cannot change the resolution or tolerance values on an existing feature class. You could create a new feature class and then import the data. The resolution values are used when storing the data, so doing an in-place conversion would be very difficult. If the resolution value is made smaller, it only matters new data; it won't affect the existing data when it's imported.
... View more
09-12-2016
03:06 PM
|
0
|
1
|
919
|
|
POST
|
It sounds like there's not geographic (datum) transformation set in the map, either when you check it now, nor when the service was created. Around 10.3, we started adding a file called gtdefaults.json to ArcGIS Server. If there's no transformation set, it will look for one in the file. Look in the pedata folder of the Server install. (or in Desktop's install). ArcMap doesn't use the file, even though it's available. Pro does. The line in the file is: [ 4269, 4326, 108190, 1, 0, 0 ], which translates into NAD83, WGS84, WGS_1984_(ITRF00)_To_NAD_1983, "apply in opposite direction" If you want to change this or just test it, edit the file, and replace 108190 with a zero. You may need to restart the service to pick up the change. Melita
... View more
09-01-2016
02:12 PM
|
2
|
3
|
2135
|
|
POST
|
You've got to do both--make sure the world file is applied to convert the raw pixel coordinates to latitude/longitude values and define the Panorama geographic coordinate system so that the system understands the earth model that's being used. I think once you do that, AND set a custom geographic transformation (between Panorama and WGS84, method: geocentric translation, parameters: zeroes), it will line up. Defining Panorama without using the world file means that the raster's extent values wrap around the entire world (they're greater than 360 degrees) thus the weird display. See this topic about world files for more information.
... View more
08-31-2016
03:16 PM
|
1
|
3
|
2463
|
| Title | Kudos | Posted |
|---|---|---|
| 3 | 2 weeks ago | |
| 1 | 01-31-2014 09:23 AM | |
| 4 | 01-18-2026 04:30 PM | |
| 1 | 01-16-2026 10:03 AM | |
| 2 | 12-02-2025 08:06 AM |