Latest Contributions by MelitaKennedy

Ah, yes, the WCCS! No idea about the connection problems. I would start a new thread in the geodatabase and ArcSDE forum with PostgreSQL version, any error messages, etc. Melita ... View more

Dennis, We have the WisCRS definitions for Chippewa county in Wisconsin as 103308 (meters) and 103408 (feet). Starting at 10.1 you could type in that value on the coordinate system page to select it directly. Also starting at 10.1, you can store the .prj file anywhere and browse to it via the Import option, not just put it in your Favorites. I don't think there's a way to get ArcGIS to recognize a WKID of 97306 directly. There's a way to add custom coordinate systems and transformations complete with well-known IDs (a back door in a sense), but we have certain supported ranges of values for different object types and 97306 doesn't fall into the right one.  Melita ... View more

I don't think you should have to do a spatial adjustment. Are you redefining the data as 17N using the Define Projection tool or the data's property page? Leave the 18N data defined as 18N, use the Project or Project Raster tools to convert it to 17N. Melita ... View more

Robert, How did you manage to use UTM? Northing values in northern France should be around 5.5million. So if I swap the order of the coordinates so that they're in northing easting z order, and add 5 million to the northings, than UTM 31 North looks like it might work. Other French systems just don't seem to fit, even if I swap the xy values. Melita ... View more

Now, I see it! Thanks, Jim! Yes, ignore my answer, a bad UTM zone is much more likely. ... View more

I'm trying to decide whether there's a size discrepancy. I can't figure out what the light blue data is supposed to represent! If there is a size discrepancy, the data that says it's using UTM 17N may really be in a UTM zone that's using feet, or a state plane zone in feet. A trick is to identify which layer is definitely not in the right plane. Remove its coordinate system (set to unknown or 'clear' depending on ArcGIS version). Now add it to ArcMap with the other data. Set the data frame's coordinate system to other possibilities like UTM 18N, the various state plane zones, etc. If you can get the other data to line up with the 'unknown' one, you've just identified its coordinate system. Post the extents of the datasets if you can't figure it out. Melita ... View more

Hi Holly, Sorry for the delay in responding. Did you enable the extension? See this topic (and the following one): Enabling the ArcScan extension. Melita ... View more

The geodesic distance is the distance on the ellipsoid/spheroid. It will be in linear units like miles or meters. The ConvertUnits is making an assumption to convert miles to degrees, probably using a mile at the equator to calculate the equivalent length in degrees. When you check that with the measure tool, the fact that the meridians (longitude lines) converge toward the pole means that the east-west distance is shorter than the north-south distance.  My guess, based on the difference in the lengths, is that the data is at approximately 41 North latitude. Melita ... View more

Hi Doug, You should not consider this a 'definitive' answer, but the three types all use parametric curves aka circular or elliptical arcs or possibly splines. Shapefiles do not support these types. Here's a topic discussing this: About editing shapefiles. Melita ... View more

If you're using the measure tool, check what type of distance it's returning. A problem with east-west distances implies to me that the geodesic distance is being returned. Melita ... View more

Hi, You should use Albers equal area or Lambert azimuthal equal area to construct a custom projected coordinate system. Melita ... View more

Hi Richard, In the Esri projection engine: longitude = 0.9194693205 latitude = 61.2762659541 UTM 31N x = 388458.9484 y = 6795497.6362 A developer I worked with suggested running the same point on a round-trip: TM0 to lat/lon to TM0. Melita ... View more

Hi Richard, If you haven't yet, you should narrow down whether the difference is occuring in the 'inverse' or 'forward' equations (or both). That is, are the software packages showing different values when unprojecting from TM 0 to lat/lon? Generally, everyone's forward algorithms (lat/lon to TM) match well, it's the inverses that have issues. The TM parameters are simple. I've seen differences when a repeating decimal like 33.3333333333 is cropped too far. And the spheroid/ellipsoid, International 1924, has simple values too. There are some spheroids where there's disagreement on what the parameters should be, so that's another to check, but it's pretty unlikely in this case. I cannot post our TM algorithm, particularly for the inverse. We use an adjusted version of the US military's version. This is not the same as John Snyder's version from Map Projections: A Working Manual, but very close. Another possibility is that the other software package has hard-coded transformation values with each coordinate reference system definition. Even though input/output are both ED50, perhaps they're using different transformations. Can you post a test point? I would suggest trying other software like PROJ4 or GEOTRANS. GEOTRANS is still online here. Melita ... View more

Hi, You could define a custom coordinate system, perhaps transverse Mercator, with the central meridian set around 54E or 55E or a Lambert conformal conic. Another possibility is to use one of the UTM zones. It looks like more of the country is in 39N, but is there's more development in 40N. If you decide to go with an existing projected coordinate system, you could choose 40N. You'll have several degrees of data 'outside' the zone, but transverse Mercator can project/unproject cleanly. Melita ... View more