Latest Contributions by MelitaKennedy

‎04-16-2019

Hi, What software version do you have? Have you recently updated the operating system? Melita

‎04-12-2019

Nope. I'm just terrible about writing and haven't done it yet. But here is an update on the additions to the setup for 10.6.0 / Pro 2.1, 10.6.1 / Pro 2.2, and 10.7.0 / Pro 2.3! GEOCON files are strictly US. We added the main NAD27 to NAD83 NTv2 for Canada. Other NTv2 files are for various countries. NTv2 is the usual file format used for geographic/datum transformations, although I've occasionally seem NADCON files used elsewhere than the US. The Vertical World 1x1 option is for the 1'x1' EGM2008 file. It's almost 1 GB by itself so has a special option to not install it. All other vertical files are in the "vertical" option. That includes geoid models and other file-based transformations for Japan, New Zealand, Switzerland, US (geoid12b), the 2.5'x2.5' EGM2008 file, and EGM84 (world). Geographic/Datum transformations 10.7.0 / 2.3 ntv2-ch03p-etrs.gsb Switzerland CH1903+_To_CHTRF95_NTv2 CH1903+_To_ETRS_1989_NTv2 BD72LB72_ETRS89LB08 Belgium Belge_1972_To_ETRS_1989_3 10.6.1 / 2.2 GDA94_GDA2020_conformal Australia GDA_1994_To_GDA2020_NTv2_3_Conformal GDA94_GDA2020_conformal_and_distortion Australia GDA_1994_To_GDA2020_NTv2_3_Conformal 10.6.0 / 2.1 BALR2009 Spain ED_1950_To_WGS_1984_NTv2_BALR2009 ED_1950_To_ETRS_1989_NTv2_BALR2009 PENR2009 Spain ED_1950_To_ETRS_1989_NTv2_PENR2009 ED_1950_To_WGS_1984_NTv2_PENR2009 UPDATE 20 November 2019!! I missed this Canadian file: Ntv2_0.gsb Canada NAD_1927_To_NAD_1983_NTv2_Canada NAD_1927_To_WGS_1984_33 Vertical 10.6.1 / 2.2 chgeo2004_ETRS Switzerland CHTRF95_To_LHN95_Height 10.6.0 / 2.1 JGEOID2008 Japan JGD_2000_To_JGD_2000_Vertical_Height_1 GSIGEOID2011 Japan JGD_2011_To_JGD_2011_Vertical_Height_1 New_Zealand_Quasigeoid_2016 New Zealand NZGD2000_To_NZGD2016_Height_1 auckland_1946_to_nzvd2016 New Zealand NZVD2016_Height_To_Auckland_1946_Height_1 bluff_1955_to_nzvd2016 New Zealand NZVD2016_Height_To_Bluff_1955_Height_1 dunedin_1958_to_nzvd2016 New Zealand NZVD2016_Height_To_Dunedin_1958_Height_1 Dunedin-Bluff_1960_to_nzvd2016 New Zealand NZVD2016_Height_To_Dunedin-Bluff_1960_Height_1 gisborne_1926_to_nzvd2016 New Zealand NZVD2016_Height_To_Gisborne_1926_Height_1 lyttelton_1937_to_nzvd2016 New Zealand NZVD2016_Height_To_Lyttelton_1937_Height_1 moturiki_1953_to_nzvd2016 New Zealand NZVD2016_Height_To_Moturiki_1953_Height_1 napier_1962_to_nzvd2016 New Zealand NZVD2016_Height_To_Napier_1962_Height_1 nelson_1955_to_nzvd2016 New Zealand NZVD2016_Height_To_Nelson_1955_Height_1 one_tree_point_1964_to_nzvd2016 New Zealand NZVD2016_Height_To_One_Tree_Point_1964_Height_1 stewart_island_1977_to_nzvd2016 New Zealand NZVD2016_Height_To_Stewart_Island_1977_Height_1 taranaki_1970_to_nzvd2016 New Zealand NZVD2016_Height_To_Taranaki_1970_Height_1 wellington_1953_to_nzvd2016 New Zealand NZVD2016_Height_To_Wellington_1953_Height_1 auckland_1946_to_nzgd2000 New Zealand Auckland_1946_Height_To_NZGD2000_Height_1 bluff_1955_to_nzgd2000 New Zealand Bluff_1955_Height_To_NZGD2000_Height_1 dunedin_1958_to_nzgd2000 New Zealand Dunedin_1958_Height_To_NZGD2000_Height_1 Dunedin-Bluff_1960_to_nzgd2000 New Zealand Dunedin-Bluff_1960_Height_To_NZGD2000_Height_1 gisborne_1926_to_nzgd2000 New Zealand Gisborne_1926_Height_To_NZGD2000_Height_1 lyttelton_1937_to_nzgd2000 New Zealand Lyttelton_1937_Height_To_NZGD2000_Height_1 moturiki_1953_to_nzgd2000 New Zealand Moturiki_1953_Height_To_NZGD2000_Height_1 napier_1962_to_nzgd2000 New Zealand Napier_1962_Height_To_NZGD2000_Height_1 nelson_1955_to_nzgd2000 New Zealand Nelson_1955_Height_To_NZGD2000_Height_1 one_tree_point_1964_to_nzgd2000 New Zealand One_Tree_Point_1964_Height_To_NZGD2000_Height_1 stewart_island_1977_to_nzgd2000 New Zealand Stewart_Island_1977_Height_To_NZGD2000_Height_1 taranaki_1970_to_nzgd2000 New Zealand Taranaki_1970_Height_To_NZGD2000_Height_1 wellington_1953_to_nzgd2000 New Zealand Wellington_1953_Height_To_NZGD2000_Height_1 UPDATE: Added Canadian NTv2 file to the 10.6.0 / Pro 2.1 entries on 20 November 2019.

‎04-10-2019

Ah, how tricky of me. I think to align the zone numbers, there are 2 spaces before the numbers for zones 1 - 9. This occurs in the "display names" used in the coordinate system picker, not in the CRS names themselves. Here's one of them: "NAD 1983 StatePlane Alaska 1 FIPS 5001 (US Feet)" Beware, when I copy-pasted it, the second space was stripped out. I had to add it back in. This is true in all the AK zones across the various geographic CRS/datums because I always copy and paste the set (in Notepad which doesn't change the spaces) and then update the geographic CRS names. Melita edit was to add phrase in last sentence.

‎04-09-2019

Yes, when we unproject/project data, we look at the actual unit that are listed in the coordinate system definition. The false easting/false northing values must be in the same unit so if you compare the int'l ft and US survey ft definitions, you should see slightly different numbers. Melita

‎04-09-2019

We have been discussing in-house about putting up a service that contains the extents for the transformations. We could do a similar one for projected coordinate reference systems, but it would be very 'busy' with multiple overlapping UTM zones, for instance, in many places. If you go to the coordinate system picker, you can enter a data extent or custom extent which will filter the coordinate systems. Melita

‎04-08-2019

There are equations here: https://gssc.esa.int/navipedia/index.php/Ellipsoidal_and_Cartesian_Coordinates_Conversion

‎04-04-2019

By coordinate size. Decimal degrees runs x/longitude +/-180 (or maybe 0 to 360) while y/latitude is +/-90. There's just about no projected coordinate system that uses that range unless you're mapping a building or playing field and using a custom definition centered on the object. I don't know what's happening with the no attributes or the error on export. It sounds like there's still problems in the spreadsheet. Double-check the column names and look for leading/trailing spaces in the names too. Take a look at this list of best practices. Melita

‎04-04-2019

In the image you posted, those coordinates are NAD83 (geographic coordinate system, decimal degrees) and not in State Plane. Try defining the coordinate system as NAD 1983 (North American 1983) instead. Melita

‎04-02-2019

I haven't looked at your algorithm in depth. Are you multiplying XYZ by the radius before starting? That may help with the height calculation.

‎04-02-2019

Hi Jacqueline, Is the same transformation set in the map? Are you using ArcGIS Desktop or Pro? Which version? As I think you know, 3 feet / 1 meter is a classic sign that a transformation isn't being applied for data that's in NAD83 versus WGS84 so it is certainly something to do with a transformation. Melita

‎03-22-2019

Which tool?

‎03-21-2019

Try defining a custom projected coordinate system for the 'ground' data. If the ground UTM coordinates are supposed to be multipled by 0.999855 to convert them to regular, grid UTM coordinates, modify the PCS parameters like this: false easting: 500000.0 / 0.999855 = 500072.5105 false northing: Zero so keep set to zero scale factor: 0.9996 / 0.999855 = 0.99974496302 All other parameters remain the same. If you right-click the NAD83 UTM Zone 12N in the coordinate system picker, you should be able to choose Copy and Modify. In the new window, Change the PCS name. Modify the 2 projection parameters. Save as a .prj file. Use the Define Projection Tool or ArcCatalog to assign this definition to your ground data. Melita

‎03-20-2019

Joshua, what coordinate system is the copy of the Living Atlas data using? Is it using the Asia North Albers definition? If it isn't and is instead using a geographic coordinate system like WGS84, GCS is native stored with longitudes between -180 and +180. Any edit will get clipped at the line, even if you're projecting the data on-the-fly to another coordinate system where the "180" line is interior to the extent of the coordinate system. If you create a dataset using the Asia North Albers coordinate system, and edit in the coordinate system, there shouldn't be a problem with merging.

‎03-20-2019

Try mapping the points using the XADJ and YADJ fields and the given coordinate system: NAD_1983_StatePlane_Arizona_Central_FIPS_0202_Feet_Intl. The false easting (x value at center of zone) of the coordinate system is 700000. The XADJ field has values around 700k. I think the XCOORD and YCOORD fields have values in 100th of a foot. This is sometimes used in surveying or engineering. I wouldn't trust the EVENT_X or EVENT_Y fields. The EVENT_Y field values are nonsensical. Melita

‎03-19-2019

You will have to identify it's current coordinate system first. It might be in latitude-longitude which ends up displayed similar to a Plate Carree projection. Is it georeferenced? That is, what is the jpg's extent? Once the coordinate system and/or georeferencing is fixed, you can project on-the-fly or use the Project Raster tool.

My Ideas

Latest Contributions by MelitaKennedy

Re: Permanent ArcGIS Desktop license stopped working

Re: Information on the Coordinate Systems desktop install?

Re: Error creating spatial reference from Alaska state plane system

Re: Coordinate question

Re: UTM Coordinate Dataset

Re: Converting geocentric coordinates to geographic coordinates and depth

Re: Invalid Sql Statement on adding x/y

Re: Invalid Sql Statement on adding x/y

Re: Converting geocentric coordinates to geographic coordinates and depth

Re: Unstable Projection? Data not lining up, why?

Re: Reprojecting circle features

Re: Convert Ground to Grid Data in GIS

Re: How do I remove the 180th meridian line on my map of Russia?

Re: X Y Data in Attribute Table Questions

Re: how to change the projection for a NASA earth pic?

Re: Append(merge,copy,..) two point Layers (GPS G...

UC 2026 presentations and more!

Re: New XY layer from Lat Long (DD) not plotting c...

Re: EPSG release and ArcGIS Projection Engine

Re: EPSG release and ArcGIS Projection Engine

Coordinate Reference Systems

Alaska GIS Users