|
POST
|
The transformation path using WGS_84(ITRF00)_To_NAD_1983 + WGS_1984_(ITRF00)_To_NAD_1983_HARN ends up basically a null transformaiton. The parameters are the same for each transformation. They were both added with the assumption that at some (in)accuracy level you can treat NAD83 / HARN / WGS84 as equivalent. Using the Florida HARN transformation is the correct way to go. To see the green and blue points line up, you need to set the map to use the same transformation as well. Melita
... View more
10-15-2019
12:36 PM
|
1
|
3
|
3124
|
|
POST
|
Hi Emmor, There are no equations available for it publicly, and I suspect that there could be copyright, trademark, or patent issues. It's sphere-based only which is not ideal and there are some significant shape distortions in certain areas (Brazil and Australia). Melita
... View more
10-15-2019
12:32 PM
|
2
|
3
|
3275
|
|
POST
|
I think the problem is thegeographic coordinate system of the OBIA file. If you're reporting the name of the GCS correctly: Geographic Coordinate System: GCS Datum: WGS84 We're not recognizing the GCS as a "known" GCS so the point data using AGD66 isn't getting converted to WGS84. If you can't change the OBIA data's coordinate system to WGS 1984 UTM 52N using the Define Projection tool, try setting the map/data frame to it. Its WKID is 32652. That should allow you to set a transformation from AGD66 to WGS84 to line up the point data.
... View more
09-17-2019
01:48 PM
|
0
|
0
|
1118
|
|
POST
|
Hello Vincent, I'm currently using a development version of 2.5, but I cannot reproduce this. Here are my steps: 1. I left the default basemap in a new map. 2. Modified the existing Europe Lambert CC to use WGS 1984 and set the map to use it. I also zoomed in to Europe. 3. Added a shapefile with European provinces/states that's in WGS 1984. 4. panned and zoomed. Just to make sure they're fine, would you please check the hardware requirements? Thanks, Melita
... View more
09-03-2019
04:26 PM
|
0
|
1
|
1200
|
|
POST
|
Oh, good. I'm glad we were able to figure it out! Melita
... View more
09-02-2019
11:51 AM
|
0
|
0
|
2362
|
|
POST
|
Okay, I just tried it. I clicked the from point location and then immediately right-clicked a target location. That opened up the Target Coordinates dialog. However, I'm running a 2.5 development version. Melita
... View more
08-29-2019
03:57 PM
|
0
|
0
|
2362
|
|
POST
|
I'm not sure I understand your steps, but when I read the help topic, I believe it says to click (left-click) the target point first, then right-click it to open the dialog box. I'm certainly done something similar when I've georeferenced data. Sometimes I quickly add the control point links, not even trying to be accurate, then edit the control point values in the table.
... View more
08-29-2019
02:17 PM
|
0
|
0
|
2362
|
|
POST
|
How did you originally zip up the feature classes? They exist within a folder that represents a geodatabase with the general files. If you zipped all the files within a geodatabase folder, extract them all and make sure the folder name matches the old geodatabase. If you zipped only certain files within the geodatabase folder...you may be out of luck. Melita
... View more
08-28-2019
01:35 PM
|
0
|
2
|
2836
|
|
POST
|
Hi Georgina, When you import the original points, you need to make sure their coordinate system is set to 4326, WGS 1984. Confirm that they're showing up in the correct location. Now... 1. If not already done, change the data frame's coordinate system to 3857, Web Mercator (or whatever coordinate system you want to data to end up in). 2. Right-click the layer and choose data, export data. 3. In that dialog, select the "use data frame's coordinate system". 4. Fill out the rest of the dialog. OK the dialog. 5. You should now have a shapefile or feature class that's been reprojected from lat-lon to Web Mercator. Melita
... View more
08-28-2019
12:45 PM
|
3
|
1
|
9285
|
|
POST
|
Offshore by Nigeria sounds like "null island". That occurs when data values are latitude-longitude but has been defined with a projected coordinate system like Web Mercator or has an "unknown" coordinate system but data values are lat-lon. A Red Sea location sounds almost like a swapping of the easting (X) and northing (Y) values. Melita
... View more
08-28-2019
11:25 AM
|
1
|
3
|
9285
|
|
POST
|
Which implies that you aren't using the project tool, but the define projection tool, or the data's property page to change the coordinate system. That is, you're right that the latitude-longitude values haven't changed, just the metadata, specifically, the coordinate system, has been changed. Ah, I think the problem occurred when you exported the data from the map after adding an XY data layer from the csv. I think that exported data still had the lat/lon values even though it was defined as UTM. Then you used the Project tool to create a new dataset in State Plane. Because the data was already messed up, the State Plane layer was also messed up. Okay, here are the steps I would follow to get correct data. 1. File - Add Data - Add XY data option. 2. After selecting the csv file, set the coordinate system to NAD 1983 (not UTM, and not State Plane). 3. Finish the tool. 4. If not done already, set the data frame/map to use NAD 1983 UTM 10N. 5. Right-click the xy layer and select data - export data. 6. In that tool, make sure the "use data frame's coordinate system" is selected. 7. Fill out the rest of the dialog and OK it 8. Now use the Project Tool to create a State Plane California III version. Melita
... View more
08-26-2019
01:57 PM
|
0
|
1
|
4463
|
|
POST
|
Hi Alexandre, You can't go by the lat and lon columns. Those are attributes in decimal degrees and aren't affected by a reprojection. The actual coordinates are stored in the Shape field. You can use the Add XY Coordinates tool to add new fields with the actual values. FYI, it's either State Plane California III or UTM zone 10 North. Melita
... View more
08-23-2019
05:41 PM
|
1
|
3
|
4463
|
|
POST
|
Are you talking about a graticule (lines of latitude and longitude) or a graticule layer? And it's being projected on-the-fly to which projected coordinate system? We did have a case in ArcMap that a graticule doesn't use enough points to build the line. You could use the ArcMap Advanced Settings Utility (in the installation folder, Utilities) to change the densification setting. Otherwise, depending on how wide an area you're displaying, there could be a projection algorithm issue, particularly if that data wasn't built in ArcGIS. Melita
... View more
08-23-2019
05:34 PM
|
0
|
1
|
491
|
|
POST
|
Queensland is pretty big. Latitude range is 19° (10S to 29S) and longitude range is 16° (138E - 154E). My colleague, Bojan, looked at it with me. Some possibilities are below: Lambert azimuthal is equal area which is not what you want, but given as an option (distorts distances and angles). He used WGS84, but GDA2020 would be another option. PROJCS["ProjWiz_Custom_Lambert_Azimuthal",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Azimuthal_Equal_Area"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",146],PARAMETER["Latitude_Of_Origin",-19.5],UNIT["Meter",1.0]] Stereographic is conformal (good angles), will distort distances and areas PROJCS["ProjWiz_Custom_Stereographic",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Stereographic"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",146],PARAMETER["Scale_Factor",1.0],PARAMETER["Latitude_Of_Origin",-19.5],UNIT["Meter",1.0]] My first thought was equidistant conic. Distances are true along longitude lines and the standard parallels. It's impossible to maintain or preserve all distances. If you can work large scale and have a projection customized for the area, distances shouldn't be too bad. PROJCS["ProjWiz_Custom_Equidistant_Conic",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Equidistant_Conic"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",146],PARAMETER["Standard_Parallel_1",-25.8333333],PARAMETER["Standard_Parallel_2",-13.1666667],PARAMETER["Latitude_Of_Origin",-19.5],UNIT["Meter",1.0]] Another some distances-preserved option is azimuth equidistant as Simon suggested. PROJCS["ProjWiz_Custom_Azimuthal_Equidistant",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Azimuthal_Equidistant"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",146],PARAMETER["Latitude_Of_Origin",-19.5],UNIT["Meter",1.0]] You'd have to compare the last two to see if one gives better results than the other for, say, area calculations. Melita
... View more
08-22-2019
12:04 PM
|
3
|
0
|
2658
|
|
POST
|
Could the existing feature class have been using a projected coordinate system rather than a geographic coordinate system (latitude-longitude)? Like maybe WGS 1984 Web Mercator (auxiliary sphere) AKA EPSG:3857? That would lead to a lot of points showing up at/near the same place. Did the new points all show up well away from where they should be? Melita
... View more
08-19-2019
01:53 PM
|
0
|
2
|
2232
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | yesterday | |
| 1 | Friday | |
| 2 | 12-02-2025 08:06 AM | |
| 1 | 12-02-2025 08:00 AM | |
| 1 | 08-10-2023 03:17 PM |