Latest Contributions by MelitaKennedy

‎03-30-2017

If you're using Mollweide (world), it's based on the WGS84 geographic coordinate system, so no transformation is needed. The same may be occurring with the Lambert (polar) coordinate system. The geographic (datum) transformation only enables with a list if it's needed--that is, when the input and output geographic coordinate systems are different. Melita

‎03-30-2017

At 10.3, we aren't doing any vertical transformations. Some support was added to 10.4.1 and Pro 1.4, with more coming in Pro 2.0. For your question, "I believe ArcMap is performing both a transformation to a different horizontal datum and a projection from a flat grid based state plane system to an elliptical geographic system", this isn't quite true. The data is being converted from a projected coordinate system, plus a gravity-related vertical coordinate system. The target is a geographic coordinate system and ellipsoidal heights based on the geographic coordinate system. At 10.3, what you would actually get is WGS 1984 for the geographic coordinate system, and the vertical/z values are still referenced to NAVD88. Vertical coordinate systems are...complicated. Most are only loosely tied to a horizontal (geographic or projected coordinate system) and even though usually because there's a transformation method that uses a grid/file of offsets and you have to have gcs connected to it to interpolate the offsets. In this case, at 10.5, we would convert the NAVD88 values to nad83 ellipsoid heights using the Geoid12b geoid model, then convert from NAD83 + NAD83 ellipsoidal heights to WGS84 + WGS84 ellipsoidal heights. If the target VCS was WGS84 geoidal heights AKA EGM2008 heights, the third step would be to convert the WGS84 ellipsoidal heights to geoidal using the EGM2008 geoid model. Melita

‎03-30-2017

Your easiest solution is training. Put the coordinate systems you want them to use into Favorites, or have a network share where they "import" from that location. A drastic solution is to make use of the projection engine's 'back door', an environment variable. Through it, you could turn off the built-in database (collection of predefined coordinate systems), then add in only a selection of what's there. It can cause issues with other parts of the software though that are looking for particular coordinate systems (if you don't include them in your custom list). Connected to that, is that you don't turn off the built-in database, but add in a new "folder" to the coordinate system picker where the folder is your company or locality name. Another way would be to code up something. I don't think you could block using the 'create new feature class' tool, but could have a custom tool that doesn't the same thing, but with the coordinate system preset. I don't have enough coding skill to even be able to tell you how to start doing that. Melita

‎03-28-2017

Hi Mark, Is the scale factor applied before or after the translation (false easting and northing) values? I'm going to assume before. UTM_easting = 410,000 m E + 0.9996899303 * local_grid_easting UTM_northing = 6,000,000 m N + 0.9996899303 * local_grid_northing To define the custom coordinate system, we want to solve for the local_grid coordinates. local_grid_easting = (UTM_easting - 410000 ) / 0.9996899303 local_grid_northing = (UTM_northing - 6000000 ) / 0.9996899303 UTM_easting and UTM_northing are actually: UTM_easting = 500000 + 0.9996*w UTM_northing = 0.9996*z w and z are "proto-coordinates". That is, the latitude and longitude values have been converted to xy coordinates except that we haven't applied the UTM zone scale factor nor the false easting value of 500000 m. The ellipsoid, central meridian and latitude of origin values have been used so far. Substitute in: local_grid_easting = ({500000 + 0.9996*w} - 410000 ) / 0.9996899303 local_grid_northing = ({0.9996*z} - 6000000 ) / 0.9996899303 local_grid_easting = 90027.9149 + 0.9999100418 * w local_grid_northing = -6001860.9952 + 0.9999100418 * z local grid parameters false easting = 90027.9149 false northing = -6001860.9952 scale factor = 0.9999100418 central meridian = utm zone's latitude of origin = 0.0 projection = transverse Mercator Melita

‎03-17-2017

You could use the coordinate system. You could also use NAD83 NSRS2007, 2011, original, HARN, etc. 1/3 arc-second is about 10 m, so the data is not accurate enough for it to matter.

‎03-17-2017

I don't know that we can do anything directly. I think it will be easier to re-georeference the data. Note the "postiveWest" for the LongitudeDirection value. You could just force the raster into 0-360 latitude/longitude that way. Or possibly georeference into a simple cylindrical system, center at 180. Melita

‎03-16-2017

I think the only doc I've written on it is on the forums. Any recent NAD83 (NSRS2007, 2011, probably CORS96 because it was used later than 1996 and possibly HARNs) versus WGS84/ITRF is now up to 1 m or more. Within NAD83, biggest jump was from original to the first HARN within a state. Some states have a 2nd or 3rd HARN / FBN adjustment which will be smaller. NAD83 original to first HARN, I'm guessing was centimeters. I checked Redlands, Californi which was about 6.6 cm. North Bay above San Francisco around 4 cm. Central Ohio, 0.263 m, New Orleans, 0.5 m. Subsequent re-adjustments should be less, normally. WGS84/ITRFxx changes should be centimeters or less. Melita

‎03-14-2017

Francesca, You need to confirm whether the data is DD MM.ssss or the more likely DD MM.mmmm as Neil mentions above. That simplifies the calculation: DD + MM.mmmm/60.0. Melita

‎03-14-2017

Hello Helle, Did you find this site: CM2.X model ocean and sea ice grids information You might want to check whether they've exported the variable you want into a rectangular grid-based file. Melita

‎03-08-2017

Maybe it has to do with server limits on the size of the requested data? See Printing and exporting maps containing service layers—Help | ArcGIS for Desktop I'm not very familiar with server/service issues, so this is just a guess.

‎03-08-2017

Hi Joss, I can only confirm what you've already found. The transformations in the EPSG registry use a polynomial method, and we don't support them yet. A possible workaround would be to identify some control points are the area of interest and run them through the transformation. You could then use the points in both systems to do a spatial adjustment, if vector, or regeoreference a raster. Melita

‎03-08-2017

The parameters aren't bad, and could be used for your area of interest. One of the standard parallels is at -22, which should be in or near your area of interest. If you do create a custom coordinate system, you could further customize the parameters. For Albers, central meridian should be place in the center of the area of interest. The latitude of origin sets the zero location of the y/northing values. So you could set it to -26 so that all Y values are positive, or put it in the center of the data. Let's say the north-south extent is from -22 to -25 or 3 degrees. One "rule" is that you place the standard parallels at 1/6 of the extent from the north and south edges. In this example, they would be at -22.5 and -24.5 or you could use 1/3 or 1/4. The false easting and false northing parameters are used to make sure all values are positive values. Melita

‎03-08-2017

Hello Pinelopi, Follow Jayanta's steps below--use the Define Projection tool to reset/redefine the coordinate system to WGS84 or Amersfoort. Once that's done, you can use the Project tool to make a copy of the data that's georeferenced to RD_New. Melita

‎03-07-2017

Hi Nielson, Esri has coordinate reference systems defined in the EPSG registry or by us. The SAD69 Albers definition was a 'sample' coordinate system that we defined over 10 years ago. We have put in any entries from http://spatialreference.org because they are not checked in any way. We don't know if a definition is really in official use or just widely used and have no way to check whether the definitions are correct or not. You can always define your own coordinate system Right-click the SAD69 Albers definition and copy and edit it. Add it to Favorites and it will be available throughout ArcGIS. Melita

‎03-03-2017

Hi Jaimie, We would not be able to provide you with any transformations, so yes, there would be no transformations. We only have one "known" definition for WGS84. Even if you created custom geographic coordinate systems that included the realization and epoch date the software has no way to handle it correctly. I don't know if the difference between your two epochs and realizations are insignificant or not. It will depend on your accuracy needs. If the data's in the US, you could try the HTDP software from the National Geodetic Survey and calculate what the differences are. Melita

My Ideas

Latest Contributions by MelitaKennedy

Re: Convertion from WGS84 to Lambert (North Pole) & Mollweide

Re: ARCMAP-TRANSFORMATION AND PROJECTION

Re: Coordinate Systems enforcement in Enterprise GeoDB

Re: Create a projection that scales CAD from Ground to Grid about 0,0

Re: Is the "(NAD 1983) point from the USGS 3DEP 1/3 arc-second layer" projection on this page: https://nationalmap.gov/epqs/ that same 'exact' projection as this Spatial Reference: 104223 (GCS_NAD_1983_CORS96)?

Re: Custom coordinate systems - Longitudinal ranges

Re: Transformations between various NAD83 and WGS84 realizations

Re: help importing coordinates

Re: Layer's don't match / Wrong Projection?

Re: Issues with FEMA NFHL layers?

Re: Transforming from Madrid 1870 to ED50

Re: Albers Conic Projection with SIRGAS2000 datum

Re: Layer's don't match / Wrong Projection?

Re: Albers Conic Projection with SIRGAS2000 datum

Re: What epoch is GCS_WGS_1984 in 10.4?

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

Re: The vertical transformations WGS_1984_To_EGM96

Re: The vertical transformations WGS_1984_To_EGM96

Coordinate Reference Systems

Alaska GIS Users