Latest Contributions by MelitaKennedy

Hi Al, ArcGIS doesn't support this definition. You should be able to 'import' the definition from your other data, otherwise, you'll have to create a new one, or modify an existing one. Modify is easier than creating a new one. Look in the projected coordinate systems, Continental and use one of the US Albers definitions. By the way, is this definition a statewide coordinate system for Oklahoma? Is it government-sanctioned? If so, I'd like to add it. Any website you can point me to? Melita ... View more

I found a few possibly related reported bugs: NIM059337: Binary Raster (1-bit TIFF) disappears at certain zoom levels when using the classified renderer. currently open; not marked as fixed. NIM067353: Tiff image shifts when zoomed out and displays in correct location when zoomed in. Fixed in 10 sp3 and 10.1. Workaround: export to a new tiff. I don't have any more information on these, and these were the only ones that showed up on a "tiff zoom" search related to v10. ... View more

I think that's 0.0005 degrees, which is not that good. I would try two things: see if you can set the georeferencing/spatial adjustment to use a conformal/similarity transformation rather than an affine one. Conformal/similarity allows a single scale value in both x/y directions, so right angles are maintained. What might also help is to project the reference data to a conformal projection for the area--like the local State Plane zone and then georeferencing/spatial adjusting to it rather than to lat/lon. Melita ... View more

Hello, When using 'high precision' geodatabases, ArcGIS looks at the coordinate system and sets the lower left (minimum x and y) xy domain values based on what's mathematically supported for the coordinate system. The xy resolution is based on the coordinate system's unit. If the unit is meter, 1/10 mm (0.0001 m) is used. If the unit is foot, for instance, the resolution is still 0.0001 m, but converted to feet. Only the minimum xy values and the resolution (and tolerance!) are actually stored. The maximum xy values are calculated from the stored values plus the maximum integer range supported, 2e53 - 1 or 9007199254740991. That's why the maximum values are so large. When using basic precision geodatabases (9.1 or earlier), they supported a max range of 2e31 - 1 or 2147483647. This more limited range means that it's only possible to map the entire world at around a few centimeters of precision and much more difficult to pick a domain for non-world areas that would cover the entire valid area of a projected coordinate system. For ArcGIS 9.2 and up, the only way to set your own domain values is to not set the coordinate system (leave it unknown) and do not take the defaults, then define the coordinate system afterwards. Do not set the minimum and maximum domain values without also setting a reasonable resolution value. If you set a small domain (that matches your data), the resolution value will be very tiny. That affects storage and processing. There's a white paper you may want to look at: Understanding Coordinate Management in the Geodatabase Melita ... View more

You can use ArcMap to help identify a coordinate system. Leave the CAD file with an unknown (undefined) coordinate system. Add it and some reference data (that does have a known coordinate system) to ArcMap. You can now set the data frame's coordinate system to possible candidates. In the US, that would include various State Plane zones (in meters, US survey feet, or int'l feet), UTM zones, state-wide grid, etc. It's less likely that city data uses one of these because sometimes there's a city coordinate system that we (Esri) just hasn't heard about. So as you set the data frame's coordinate system, the unknown data will continue to be displayed where it was. That is, the software can't do anything to it. The reference data will be projected to the new coordinate system. If you can get the reference data to line up with the CAD data, then you've discovered the coordinate system. Another trick is to look at the coordinate values. If the X or Y values have at least 6 digits, then the data may well be using a 'known' coordinate system. Five or less usually means a local system. Melita ... View more

I am trying to get two shapefiles and a raster image that I layer stacked in ERDAS to overlap in Arcmap. I have projected all three into the same projection (WGS_1984_UTM_Zone_17N) but they are not overlapping. I have tried this in ArcMap through the Projection toolbox, in ArcCatalog, and in Erdas with the raster image. I have also tried converting the raster image into a grid and trying to reproject it that way. I also tried to georeference the files. So the extents are off and so are the datum even though the files are of the same section of Florida and are in the same projection. When I input the files into ArcMap all three look like they are different sizes. I am not sure how to fix this and I am at my wits end. Any help wold be greatly appreciated!! Thanks. ArcMap is likely reading any internal georeferencing/coordinate system information for the rasters. If they have different extents, they're almost certainly georeferenced to different coordinate systems. Redefining the information (using data property page in Catalog or the Define Projection tool) just updates the metadata, not the actual data extents or coordinate values. For US data, you could have a layer using a state plane zone instead (if the relative size is off 3x, could be feet vs meters) or one in geographic (decimal degrees). You're going to have to figure out the 'native' coordinate systems of the data, or georeference, then define the coordinate system to what you used for the georeferencing. But georeferencing should be a final can't-figure-it-out-otherwise step. What extents are you seeing (check each layer individually in ArcCatalog or a new ArcMap session) and what general location/area do the different layers represent? Melita ... View more

Diana has the answer. When you import the point data, switch the columns that you're using for 'x' and 'y'. The -80 values are longitude and correspond to 'x' (easting) while the +25 values are latitude and correspond to 'y' (northing). Melita ... View more

If the original value came from a ground survey, you're unlikely to match it, although that seems quite a bit off! You may be running into a few things: projection used to calculate the areas isn't equal area, or a grid vs ground, or both. The data frame may be using a state plane or UTM zone. Both are conformal and maintain shapes, not areas. A projected coordinate system is also done relative to the ellipsoid (spheroid) surface, not the elevation/ground and that can also cause distortion. 1) How close are the areas of the entire parcel? 2) Try using an equal area projection like Albers or Lambert azimuthal, modified to put their centers close to the data Melita ... View more

Helen, You're so close! The shapefile's extents exactly fit the projected coordinate system definition so as long as it's assigned the MOLDREF99 definition, it's fine. The file with lat/lon coordinates needs to be defined with a geographic coordinate system--to match the values. The coordinate system definition must always match what the coordinates currently are using. Once that's set, then ArcMap can project the values on-the-fly to a different coordinate system, or you can use the Project Tool to create a copy in a different coordinate system. Melita ... View more

Convert the values to decimal degrees. Windows calculator can do this. It supports the coordinate format DD.MMSSsssss. As an example, enter 0.0028125 Check on the Inv button Click the dms button. Or divide the seconds value by 3600. 28.125" = 0.0078125 18.75" = 0.005208333333 (unfortunately, a repeating decimal) Melita ... View more

Hi, "Inconsistent extent" should occur only if the data already has a defined coordinate system. It's triggered because the data's extent doesn't match what the coordinate system supports. One example is if the coordinate system is a geographic one using decimal degrees, but the data extent has values that too large for decimal degrees. Or it can occur if the data has a projected coordinate system, but the extent is too large for the valid mathematical area of the coordinate system. Whatever's there may be confusing spatial adjustment. Try 'clearing' the coordinate system in ArcCatalog before adjusting it. You're positive that it isn't in a known system? Can you post the data extent and what location it represents? Melita ... View more

Hi Ben, Two things to check--spatial index (does it look reasonable?) and try using sdelayer -o alter to update the layer's extent with the -E option. sdelayer -o alter -l <table,column> [-e <entity_mask>] [-M <minimum_id>] [-S <layer_description_str>] [-k <config_keyword>] [-i {<service> | <port#> | <direct connection>}] [-s <server_name>] [-D <database_name>] [Spatial_Index] [-L <ON | OFF>] [-E <{empty | calc | xmin,ymin,xmax,ymax}>] [-G {<projection_ID> | file=<proj_file_name}>] [-P HIGH[{-R <SRID>|[Spatial_Ref_Opts]}]] -u <DB_user_name> [-p <DB_user_password>] [-N] [-q] Melita ... View more

Hi Scott, If you're seeing direct east-west or north-south offsets between the (undefined) local grid data and UTM-based data, you should be able to adjust the false easting and/or northing parameter values to get rid of the offsets. That is, adjust the data frame's custom projected coordinate system. That values I recommended were based on your calculations, I've found that often these values need modified to get the best fit. Once you have the best-fit coordinate system set in the data frame, make sure it has a easily-identifiable name and save it to Favorites. Here's awkward part. Because ArcGIS doesn't know what folders it can write to, it saves a .prj file of the Favorite in: XP: C:\Documents and Settings\your_login\Application Data\ESRI\Desktop10.0\ArcMap\Coordinate Systems Win7: C:\Users\your_login\AppData\roaming or local\ESRI\Desktop10.0\ArcMap\Coordinate Systems Find the file and copy it to your ArcGIS home, Coordinate Systems, Projected Coordinate Systems folder. Now you can access this definition with Define Projection Tool or the Project Tool, for instance. If you can't get a good fit using a custom projected coordinate system, you might have to use the spatial adjustment toolbar to 'force' the UTM data to local grid. Melita ... View more

Hi Scott, Geographic transformations are designed to convert between two geographic coordinate systems only, not between two projected coordinate systems. The X/Y/Z axis translations are offsets in the 3D geocentric frame (X and Y are in the equator's plane, Z is polar axis), which is why the results aren't correct. Instead, I think you should try to make a custom projected coordinate system for your local grid data. Based on what you've posted, it looks very possible. You can't use the standard UTM definition with it, because the local grid is definitely not in UTM. The easiest way to do it is to remove any existing coordinate system from the local grid data--"clear" it using the data's property page in ArcCatalog. Add it and the reference data to ArcMap. Set the data frame's coordinate system to your calculated parameters. You may need to adjust the parameter values, but ArcMap will convert the reference data to the new system automatically and you'll be able to immediately check the fit. Use the UTM zone definition as the basis, but change these parameters: false easting: 4254.108m false northing: -5717240.125m Scale factor: 1.0000768092 (0.9996 * 1.000477) other parameters stay the same You probably also need to multiply the false easting/northing values by 1.000477, but try this first and see what it looks like. Hope this helps, Melita ... View more

You might check with the local state or county to see if they've acquired better resolution data (like LIDAR). Melita ... View more