Latest Contributions by MelitaKennedy

(use a copy, of course!) Unproject the points to ED50. Transform it to WGS84. Redefine it as ED50 and project to ED50/UTM 29N. That might do it. ... View more

Hi Mark,  There are some online tools which will take a point or extent and suggest what projected coordinate system it might be using, but I don't know of one that would try to figure out blunders.  The amount that the points are offset does look like a GCS/datum issue. There is a chance there could have been DMS or degree decimal minute data was mistaken for decimal degree data (or vice versa).  WGS72 could have been used rather than WGS84, but they differ only by a few meters.  I took a random point in Portugal (40 -8) and transformed them using EPSG:6189 then projected both to 32629 (WGS84 UTM 29N) to get a feel for the offset assuming someone didn't correctly transform the data: F:\arcgis\arcsde>forward 32629 Esri Projection Engine version 10.6.0.8000 -7.999086890966467 40.00081355417707 -8 40 ^Z 585437.3925654054 4428327.238551771 585360.4618427715 4428236.064633091 They differ by around 119 m. I then tried the same thing with ED50 and EPSG:15964 F:\arcgis\arcsde>forward 23029 Esri Projection Engine version 10.6.0.8000 -8 40 -8.001403182178615 39.99876783870072 ^Z 585364.3213782879 4428311.984619451 585246.0698706302 4428173.876215876 These differ by around 181 m, so that does fit with the offsets you're seeing. A point (at that location) in ED50 moves southwest when converted to WGS84/ETRS89. You can look at your data to see which way it should move and that may help you figure out what happened. Assumed to be in WGS84 when it was really ED50 or opposite? Etc. Hope this helps, Melita ... View more

I'm not an ArcGIS Engine versus Desktop expert, but Engine release numbers do align with the Desktop (and Server) release numbers. What is the format of the data you're preparing? Is it geodatabases? Sometimes there are schema changes within the geodatabases or in a map document (mxd) that makes them unable to be read by earlier versions. In that case, one solution is to continue to use an older version of the geodatabase. There could also be new geometry types that aren't supported in 10.4.1. That could also cause problems. In ArcGIS 10.6, you can save a map document back to earlier versions if necessary.  ... View more

The graphics card does meet the recommended (and not just the minimum) specifications for ArcGIS Pro 2.1.  ... View more

I'm not clear on your workflow. You might want to try using the spatial adjustment tool, or the georeferencing tool on the oriiginal CAD data if you need to move CAD data in a "local" coordinate system to a projected coordinate system like a state plane zone.  Every layer gets a spatial reference. A spatial reference has a coordinate system (like state plane or just geographic/lat-lon) plus some storage and processing values. Out of bounds errors happen when the data is outside or getting moved outside the xy domain / extent of its spatial reference. Melita ... View more

What Dan says. We need to see some sample coordinates and where the data should be (city, county, etc.). If there's a privacy concern you could email it to me directly (mkennedy at esri dot com) and I'll delete it when finished, or try obfuscating the coordinates. Melita ... View more

Are you sure it's really UTM and not a GK zone? They often have the zone number added to the false easting coordinates. We have entries for Germany, Poland, Croatia, Slovenia, Bosnia and Herzegovina, and Czech Republic. If you're sure that it's UTM 33N, copy and modify that definition (change the name)--add the 5 million to the false easting. Assign it to the data using Define Projection Tool or the data's property page. Use the Project Tool to convert to the regular UTM 33N definition.  Melita ... View more

Unfortunately, it's not planned to update ArcGIS Desktop with both feet versions. Desktop uses a restricted list of units and there's no plans to change that.  Another alternative might be to use the Field Calculator if the data is already using international feet. ArcGIS Pro is much more flexible when it comes to unit-handling. Melita ... View more

The points data look better to me than the census data. I think the problem is with the census data. The coordinate extent doesn't look like web Mercator to me. Census data is almost always in latitude-longitude. I can see someone putting it into Web Mercator because they plan to make a web map out of it, but that means the data has had some processing. If you add it by itself to ArcMap, try switching the display units to decimal degrees (map properties, General tab). The status bar at the bottom of the map will now display lat/lon values. Do they make sense? AKA southern California is around -118 34, Miami around -80 26, and Chicago around -87 42?  If they don't, then the coordinate system is incorrectly defined. If you used the Project Tool to get to this point, the previous coordinate system was probably also incorrect.  EDIT - Took a look at the census extents Here's the equivalent extents in longitude, latitude order: -63.91699778984197 -14.96371239524974 29.83872538339628 38.08788461002423 The longitude values are in the Atlantic and the latitude values don't even cover the entire lower 48 states. As I mentioned earlier, if you don't have the original census data file, try using the Project Tool to go back to its previous coordinate system and please post those values (and the coordinate system). If you want to send me either or both files, I can take a look at them. Melita mkennedy at esri dot com ... View more

It looks like there are graticule lines identifying latitude-longitude so you could use those. If they aren't labeled with latitude-longitude lines, are there any coordinates on them at all? Is there any projection, datum, or ellipsoid information anywhere?  Who's the publisher and when was it published? That can also help narrow down what coordinate system was used. Melita ... View more

Hi Cliff,  I fixed the extent issue in 10.6 / Pro 2.1, so it should get picked up in Collector soon. Melita ... View more

If the Esri projection engine is being used, it does an exhaustive check. Names must match (although there's some flexibility with underscores, white space, alias) and values must match. The name you have matches the Esri name, not the EPSG name (see http://www.epsg-registry.org).  http://spatialreference.org has a superset of EPSG, Esri, plus whatever other information someone can find for a particular coordinate reference system, including plenty of duplicates as individuals add entries.The "ESRI WKT" string in the 32041 entry is in the Esri style, but the name is the EPSG name. The EPSG Geodetic Parameter Registry (disclosure: I'm on the subcommitte that maintains it) and Esri both curate additions and changes to our sets of coordinate reference systems and transformations. Melita ... View more

Morten Nielsen‌ Morten, Rob checked the WKT in the projection engine, and it was able to find the WKID. The only difference I see is that the standard parallel 1 and 2 values are swapped. In the projeng, we internally swap them because our convention is lower/smaller value is in SP1, but EPSG and some others use a north-to-south convention. WKID is 32041. EDIT: Fixed the WKID number. Melita ... View more

Can you post the contents of the prj file? Or give its well-known / Authority ID? If you don't want to post it it publicly, send it to mkennedy at esri dot com. Melita ... View more