Latest Contributions by MelitaKennedy

‎05-31-2019

Hi Chuck, I personally use "geographic coordinates" to mean latitude-longitude. Sometimes that could include ellipsoidal heights (heights/depths relative to the spheroid/ellipsoid surface). I have seen others, including in Esri documentation, use "geographic coordinates" to mean the positions of a thing so the coordinates could be in a "geographic" or a "projected" coordinate system. When Esri (and others) display data that's stored in latitude-longitude as a 2D map like in ArcMap, it usually using Plate Carree or pseudo-Plate Carree where the degrees of the latitude-longitude values are treated as if they're linear values. The regular Plate Carree projection just scales the degrees into meters--that is, the math of the projection is not complicated. A graticule is a set of points or lines that show where the lines of latitude and longitude are in that map's projected coordinate system. So you actually have to convert the latitude-longitude into the map's coordinate system in order to place them properly. If the display is truly 2D, then you can add 3D data to it, but usually not see the 3rd dimensional data except by querying a feature's properties. If you instead have a 2.5D or 3D display, then you can see the 3D properly placed and usually pan and tilt around it. It can get strange because much 3D GIS data is not using the same reference surface for the horizontal and vertical coordinate systems. That is, if the vertical coordinate system (VCS) is for orthometric/normal/geoidal/gravity-related/MSL/LLWS/etc., the "zero" surface for those is not the same as the projection surface of a PCS, nor a GCS's ellipsoidal surface. so that can cause some confusion. Maybe that's why AutoCAD doesn't want to display latitude-longitude plus gravity-related heights/depths, but this is pure speculation on my part as I haven't used AutoCAD. Melita

‎05-17-2019

If the z/vertical values are ellipsoidal, the VCS must use the same datum as the horizontal/geographic coordinate system. We don't have an ellipsoidal Monte Mario VCS. Could the z values be on Genoa? or EVRF2000 or EVRF2007?

‎05-17-2019

Thank you for posting that information!

‎05-16-2019

The format doesn't look familiar to me. Can you tell us approximately where the data is supposed to be? I'm assuming E = easting and N = northing but the trailing number is odd. It wouldn't be unusual if the numbers were, for example, 1392250 or 139225 or 13922500 350680 or 3506800 I've seen 13 million eastings in state plane zones, particularly if in feet, but that's unlikely for military-based numbers. They don't match georef or GARS. I guess if you're working with military data, you could try contacting NGA, the Coordinate System Analysis group, https://www.nga.mil/ProductsServices/GeodesyandGeophysics/Pages/CoordinateSystemAnalysis.aspx Melita note: edited 5:15 p.m. PDT to fix a number because I'd repeated one of them.

‎05-14-2019

Are you using the Project Tool and setting the output coordinate system to ground system? Melita

‎05-13-2019

Just to confirm, are the extensions turned on in the software itself? In 9.3.1, select Tools > Extensions > check on licensed extensions Melita

‎05-10-2019

I would suspect that there's been an operating system update or other software update sometime since last year that may be interfering with the software. What operating system are you using? Does ArcMap and ArcCatalog work? Are the extensions turned on? What error message do you get when you attempt to use one of the extensions?

‎05-09-2019

Hi Joseph, Can you give me some more information? Let me make sure I understand the scenario too. You have a layer in a map (or scene). You change the source data of the layer. Are the two source datasets using the same data format (raster/tiff vector/file gdb feature class)? What is the data format? What are the details of the two spatial references? Thank you, Melita

‎05-07-2019

Hi David, The base coordinate reference system is NAD83 State Plane Colorado North (US survey feet). The flattening you listed is rounded compared to what's normally used, so I would just use the standard NAD83 definition. You've got scale, rotation, translation values so you could try georeferencing the CAD data this way: Defining a coordinate transformation It also talks about setting up a world file instead. With either method, you would assign (use a prj file) that has the NAD83 State Plane Colorado North (US survey feet) definition. It's sometimes also possible to directly design a coordinate system that incorporates the translations, scale, and rotation values. Your case would be difficult because of the rotation. Lambert conformal conic doesn't have that parameter so you would have to try adjusting the central meridian value instead. It would be tedious, so I would try the other solutions first. If you want, please send me an email (mkennedy at esri dot com) and I can send you two documents that discuss this. Melita

‎05-07-2019

Hi Sarah, They aren't, but send me an email (mkennedy at esri dot com) and I'll send them to you. Melita

‎04-26-2019

My first thought was UTM too, because State Plane zones in California are bigger east-west than north-south and use Lambert conformal conic. The x/easting values are in the millions, while the y/northing values are 6 digits. Try a UTM zone, probably zone 10 N (North). It's harder to figure out the geographic coordinate system because they usually only change the positions of the data by a meter or less (unless it's NAD27 vs NAD83). Try NAD 1983. Melita

‎04-23-2019

Hi Kylie, Mark, GDA2020 is a null transformation to WGS84 (G1762) or ITRF2014 AT 2020.0, not to generic WGS84. Although EPSG does have a null transformation (parameters are zeroes), EPSG:8450, its (in)accuracy is up to 3 m. Because we already have a null/zeroes transformation between GDA94 and WGS84, we don't want to add the same for GDA2020 to WGS84. It could create a 'cycle' with data going through the different transformations and being labeled as GDA94 or GDA2020 when it's really the other one. Plus overlaying two WGS84/Web Mercator layers which are actually GDA94 and GDA2020 will cause problems. We're still discussing it here. Melita

‎04-19-2019

I can't tell from your post. Are you assigning NZTM to the data or NZGD2000? You need to assign a geographic coordinate system to the data. Melita

‎04-16-2019

If you're on 10.3.1, and upgraded to Windows 10, check out this technical article: https://support.esri.com/en/technical-article/000013232

‎04-16-2019

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

My Ideas

Latest Contributions by MelitaKennedy

Re: Geographic Coordinates

Re: Problems importing a standalone table of coordinates

Re: Can't identify coordinate system

Re: Can't identify coordinate system

Re: Convert Ground to Grid Data in GIS

Re: Why doesn't my 3d analyst work any more in ArcGIS 9.31?

Re: Why doesn't my 3d analyst work any more in ArcGIS 9.31?

Re: Spatial Reference is not correct after changing data to new source in ArcGIS Pro

Re: Create a projection file

Re: Local projection to UTM 9

Re: Projection: Find based on known location and Coordinates?

Re: GDA2020 and Web Mercator

Re: How to plot points in New Zealand?

Re: Permanent ArcGIS Desktop license stopped working

Re: Permanent ArcGIS Desktop license stopped working

Re: EPSG release and ArcGIS Projection Engine

Re: EPSG release and ArcGIS Projection Engine

Re: The vertical transformations WGS_1984_To_EGM96

Re: The vertical transformations WGS_1984_To_EGM96

Re: NAD83 to NAD83 2011 transformation methods

Coordinate Reference Systems

Alaska GIS Users