|
POST
|
Thanks, Steve. I forwarded it to the Legal department.
... View more
05-16-2017
08:52 AM
|
0
|
0
|
1343
|
|
POST
|
Maybe you'd like to revise those years? (10.2.2 - 2014; 10.3.1 - 2015) Based on the current schedule as I know it, Dan has the right idea.
... View more
05-12-2017
12:27 PM
|
1
|
1
|
1496
|
|
POST
|
There's no particular heading that needs to be used. You could use "a" and "b" as long as you correctly identify which one is which. I would stick to x / y or easting / northing respectively. Can you post more about the data like some sample coordinates? You say that they're GDA94 MGA 54, but could they be latitude-longitude (thus GDA94) instead? How far off are they from where they should be? Are the values importing correctly? That is, if you load the feature class by itself into a new map/data frame and check the coordinates of a point, are the coordinates the same as those in the spreadsheet? Could the x and y fields have gotten swapped? Melita
... View more
05-12-2017
12:23 PM
|
2
|
5
|
3179
|
|
POST
|
Try redefining the data to Esri's version of the coordinate system. If the GCS or datum names don't match, it won't find the available transformations.
... View more
05-10-2017
04:28 PM
|
1
|
0
|
2014
|
|
POST
|
Clarke 1880 RGS is an ellipsoid/spheroid, not a true geodetic datum (geographic coordinate system). If that's all that is listed (particularly for GRIDs or coverages), the software will create a "Clarke 1880 RGS-based" geographic coordinate system. Because it's not a true geographic coordinate system, we have no transformations to or from Clarke 1880. What location does the data represent? That information may help us identify the true geographic coordinate system. Google Translation: Clarke 1880 RGS est un ellipsoïde / sphéroïde, pas une véritable donnée géodésique (système de coordonnées géographiques). Si c'est tout ce qui est (En particulier pour les GRID ou les couvertures), le logiciel créera un système de coordonnées géographiques "Clarke 1880 RGS". Parce que ce n'est pas un véritable système de coordonnées géographiques, nous n'avons aucune transformation vers ou depuis Clarke 1880. Quelle est l'emplacement des données? Cette information peut nous aider à identifier le véritable système de coordonnées géographiques. Melita
... View more
05-08-2017
01:55 PM
|
1
|
0
|
1034
|
|
POST
|
Yes, that's correct. You can also have movement due to subsidence, glacial rebound, tectonic motion (earthquakes), etc. US control points have a setting for "stability" even. We're just now adding the WGS84 realizations to 10.5.1, and Pro 2.0. However, we have no transformations between them, as none have been published. There are a few ITRFyyyy-WGS84(Gxxxx) transformations, but none are official. Melita
... View more
05-05-2017
02:56 PM
|
1
|
2
|
4921
|
|
POST
|
Hi Loren, As far as I know, PROJ.4 hasn't implemented this map projection method yet. EPSG now has it, calling it "Colombia Urban", WKID:1052, so it would be relatively simple for someone to implement it. You might add an issue to the proj.4 GitHub repository. It's very unusual and there's not really another projection like it that I know about. It actually has different x and y scaling so there isn't a single scale factor. Melita
... View more
05-01-2017
03:39 PM
|
2
|
0
|
1059
|
|
POST
|
It could be as simple as the data had the correct gcs/datum at one point when passed through a software package or was reprojected where that gcs/datum isn't supported. The software kept what it could (the ellipsoid) but lost the rest of the information. The GRS80 page isn't wrong, but no one "realizes" an actual geodetic coordinate system as grs80 directly. The closest is ITRFxx by the IERS who insist that the ITRFxx (international terrestrial reference frame, xx = year) has no ellipsoid at all, although they'll say to use GRS80 if you convert from the "native" XYZ coordinates into latitude-longitude-ellipsoidal height values. Next closest would be the US military's WGS84 but you'll notice that they don't call it GRS80. I, personally, would think of GRS80 as more of a theoretical surface. WGS84, ITRFxx, etc. "realize" by tying it to coordinate points on the ground, as it were.
... View more
04-28-2017
03:47 PM
|
1
|
1
|
22187
|
|
POST
|
We don't have any transformations between GDM2000 and WGS84. There are no publicly available transformations. You need to talk to JUPEM, if you need that level of accuracy. Melita
... View more
04-27-2017
02:08 PM
|
2
|
1
|
2151
|
|
POST
|
I thought I answered this elsewhere, but maybe it was someone else asking? GRS80 is an ellipsoid/spheroid, not a true geodetic datum / geographic coordinate system. If that's all that is listed (particularly for GRIDs or coverages), the software will create a "GRS80-based" geographic coordinate system. Because it's not a true GCS, we have no transformations to or from GRS80. It's more likely that the data is on NAD83 or one of its realizations. If the raster's cell size is larger than a meter or so, you could redefine them directly as WGS84 UTM zone X and then project them to Web Mercator. Or redefine the GCS portion as NAD 1983 (name may be "GCS_North_American_1983"). Or if you know that they're really on a different realization of NAD83, like NAD 1983 (2011), redefine the GCS as that. Or use the create custom geographic transformation tool. You'll need the exact GCS definition from the raster. If there's no need to transform (you can treat NAD83 and WGS84 as equivalent (cell size > 1-2 meters)), use the null transformation method or the geocentric translation (leave the parameter values as zeroes). If the cell size is smaller, try to do some research on what NAD83 realization was used to georeference these images. WIth that information, I can suggest what transformation to use. Melita
... View more
04-27-2017
02:03 PM
|
1
|
4
|
22187
|
|
POST
|
That's weird because we added zones 1-4 in a very, very early release, well before 9.3.1. Zones 0 and 5 were added in 9.3. They should be in National Grids\Finland. Are the other Finnish coordinate systems there? The GK zones? I've see a problem with prj files if you are using a localized OS, but the decimal symbol doesn't match the code page. For instance, the decimal symbol is set to comma, but using a US code page / localization. Melita
... View more
04-27-2017
01:52 PM
|
1
|
0
|
997
|
|
POST
|
Although you've just missed it this year, every spring there's an Esri Petroleum GIS conference in Houston. You also may want to check out the APSG, Association of Petroleum Surveying and Geomatics, http://www.apsg.info/ Melita
... View more
04-18-2017
03:49 PM
|
1
|
2
|
2094
|
|
POST
|
It is planned for an upcoming release! Generally, we're not supposed to promise which release will have new functionality, until very close to the end, but we are close to the end...you should be able to create custom coordinate reference systems in 2.0.
... View more
04-13-2017
03:01 PM
|
0
|
0
|
1031
|
|
POST
|
I;m sorry for the late response. I usually only look at the questions. Most of the extents come from the EPSG Registry. They are consciously given very roughly and are the bounding boxes of a set of area polygons. Esri doesn't use the polygons (yet). They're also all in WGS84 because if you used different GCS, you'd have to also state which transformation to use to get them to WGS84/ITRFxx. The extents are imprecise enough that it doesn't matter. You won't be able to differentiate UTM zones based on different GeoCRS unless the data itself shows the same location AKA has the same extent once you put them into the same GeoCRS. I've seen one or two other identify-the-CRS tools, and they give a list of candidates. Melita
... View more
04-13-2017
02:57 PM
|
0
|
1
|
1869
|
| Title | Kudos | Posted |
|---|---|---|
| 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 | |
| 1 | 12-02-2025 08:00 AM |