Latest Contributions by MelitaKennedy

I have a DWG with these notes: 1. All coordinates are ground & adjusted to NADCON, +- 12 to 18 cm. 2. NAD 1983, NAVD 1988 3. Combine Factor = 0.99969305 4. Benchmark used NGS J-432, Published Elevation 5129.15 5. NM State Plane, Western Region I want to bring the file in to an existing ArcMap project where the Data Frame coordinate system is NM State Plane West NAD 1983 feet. I have tried to transform the file by adjusting the scale under the layer's Transformations tab but the points aren't moving where I know they should be located. Specifically, I click the Enable Transformations check box, click the Rotate, Scale, Translate radio button, and enter values of 0.99969305 or 1.00030695 in the Scale box. (I have tried both numbers.) What am I doing wrong? I've done it in ArcMap before but it's been a few years and obviously I am missing something. Aaron Allen Albuquerque, NM Hi Aaron, btw, when I inverse your scale values, I'm not matching. My calculator reports 1/0.99969305 is 1.00030704 while 1/1.00030695 is 0.99969314. Anyway, another way is to incorporate the combined scale factor (CSF) into a custom projected coordinate system. What you'll need is the CSF that converts to ground. You multiple the false easting, false northing, and scale factor values by the CSF to create new projection parameter values. Thus, the new pcs reflects the 'ground' coordinate system. I would suggest modifying the pcs name to reflect that the parameters are adjusted. Melita :cool: Read this section if you're interested in the math: When a projection is done the final values are calculated by: X_grid = false easting + sf*(bunch o'math) Y_grid = false northing + sf*(bunch o'math) where the other projection spheroid parameters are used to calculate the 'base' XY values. A CSF is applied to the final values: X_ground = CSF*X_grid Y_ground = CSF*Y_grid substituting in: X_ground = CSF*(false easting + sf*(bunch o'math)) Y_ground = CSF*(false northing + sf*(bunch o'math)) or X_ground = CSF*false easting + CSF*sf*(bunch o'math) Y_ground = CSF*false northing + CSF*sf*(bunch o'math) So we get: new false easting = CSF*false easting new false northing = CSF*false northing new scale factor = CSF*sf ... View more

Would anyone have a clue as to why it is that when I publish a map with the WGS 1984 Web Mercator (Auxiliary Sphere) the WKID is defined as 3857. In the help docs it states that it should be 102100 but I can never get my map services to show up that way. Further looking at the WGS 1984 Web Mercator (Auxiliary Sphere) prj file shows it is defined as 3857, so how does any one else get 102100 to show in the REST page? Even if I manually change the code in the prj I cannot get it to say 102100. Does anyone else have this issue? Running AGS 10 ADV ENT. The WKID was changed at version 10 to 3857. This is because this version of "web Mercator" closely aligns with the EPSG dataset's entry (http://www.epsg.org). Doc's out-of-date, I'll ask that it be updated. The multiple codes are due to release timings: A. 102113 (because that was the only way we could emulate the web services' definition) B. 102100 added next, using a differently built, but *completely* equivalent, definition C. EPSG then added 3857 (and deprecated their earlier 3587 entry which was closer to how 102113 was defined) D. We changed the ESRI 102100 code to EPSG 3857. Melita ... View more

Hey Derek- your link sends me to a place called salesforce.com; is this where we need to go and then sign up for a free 30 day trial?  Seems kind of odd... I had the same problem when the Ideas site was first opened. Try http://ideas.arcgis.com instead. Melita ... View more

Hello - I am using a Geometry Service in the Flex API, to convert a point from WebMercator to Albers. The direct conversion did not work, so I first converted the point to WGS 84, and that worked fine. When I go from WGS 84 to Albers Equal Area Conic, though, the code errors out. If I try to do the projection using the ESRI sample service at http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Geometry/GeometryServer/project with input wkid= 4326, output wkid=9822, geometry = { "geometryType":"esriGeometryPoint", "geometries":[{"x":-89.137,"y":28.99}] } I get 'error projecting geometries' as you can see here http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Geometry/GeometryServer/project?inSR=4326&outSR=9822&geometries={%0D%0A%22geometryType%22%3A%22esriGeometryPoint%22%2C%0D%0A%22geometries%22%3A[{%22x%22%3A-89.137%2C%22y%22%3A28.99}]%0D%0A} How exactly do I get the lat/long projected to Albers? Todd, 9822 is a code for the Albers map projection. That is, the algorithm, not for a completely-defined projected coordinate system. What parameters, GCS, and units do you want to use? Perhaps we have one already defined. There are several variants for US/North America, and some for other continental regions. Melita ... View more

I want to project a raster from WGS84 Geographic to NameBessel2217 which is the projected coordinate system used in Namibia. The problem i have however is that there are a entire list of possible transformations and i am uncertain which to use. Can anyone offer any advice on which transformation to pick? Thanks Hi, Can you give the details on the target coordinate system? Bessel is a spheroid (ellipsoid), not a datum. EPSG (http://www.epsg.org and http://www.epsg-registry.org - online version is running slowly right now; the subcommittee is working on the problem) only lists Schwarzeck (although the Cape and Hartebeesthoek probably also apply, but they don't use Bessel ellipsoid) which does use Bessel Namibia. The transformation to use would be Schwarzeck_To_WGS_1984_2. We have a UTM zone based on Schwarzeck. Otherwise, EPSG lists several zones based on Lo22. These use a south-west oriented system that we don't support. I've been told that you can emulate the Lo systems, by using -1 for the scale factor. Melita ... View more

I run ArcMap 9.1. I have some .dwg files without projections that I would overlay on aerial photos. From everything I've read, it seems that the georeferencing toolbar is the best way to accomplish this, but whenever I load the .dwg files into ArcMap, they are not recognized by the toolbar. The toolbar does work because I have used for other types of image files. Can anyone help me out with this one? Thanks. Austin Austin, In 9.1, the georeferencing toolbar didn't support CAD files yet (unless scanned images). Instead you need to identify two pairs of coordinates in the CAD's coordinate system and in the target coordinate system. You can put them into a CADname.wld file: x1_source, y1_source, x1_target, y1_target x2_source, y2_source, x2_target, y2_target If you open the CAD layer's property page (in ArcMap), you can add some transformation information there instead. There's information on this in the help. Here's the web link: http://webhelp.esri.com/arcgisdesktop/9.1/body.cfm?tocVisable=1&ID=222&TopicName=Applying a coordinate transformation to a CAD layer or via your installed help, ArcMap, Creating Maps, Applying a coordinate transformation... Melita ... View more

Hello and thank you in advance. I am still, unfortunately, a little confused on the projection for posting data in Google Earth: I understand that GE and MS apps use a spheroid only model, which is the projection ESRI calls: Geographic Coordinate System, (spheroid-based)  "GCS_WGS 1984 Major Auxiliary Sphere" or Projected Coordinate System (World) "WGS_1984_Web_Mercator" Whereas ESRI uses a spheroid or ellipsoid model, which is the projection ESRI calls: Geographic Coordinate System (World)  "GCS_WGS_1984" or Projected Coordinate System (World) "WGS_1984_Web_Mercator (Auxiliary Sphere)" The instructions in Technical Article ID: 34749 say when using 9.3 SP1 to use the: Predefined Projected Coordinate System (World) "WGS_1984_Web_Mercator" HERE IS MY PROBLEM: When projecting from NAD83 to Projected WGS_1984_Web_Mercator in the toolbox, there is a message that this is an undefined projection, and I can only do it with a double: NAD_1983_To_WGS_1984_5 AND WGS_1984_Major _Auxiliary_Sphere_To_WGS_1984 The same is true (obviously) if I try to project from NAD83 to Geographic GCS_WGS_1984_Major_Auxiliary_Sphere Isn't this exactly the same as just going from NAD_1983_To_GCS_WGS_1984, which is the ESRI model, not the Google Earth or MS (Bing) model, right? In the end, projecting to GCS_WGS_1984 is equivalent to projecting to PCS_WGS_1984_Web_Mercator which is equivalent to projecting to GCS_WGS_1984_Major_Auxiliary_Sphere The only difference is that the denominator of the flattenting ratio for the PCS_WGS_1984_Web_Mercator is infinity instead of 298.257224.   No matter what, the locations lie directly on top of one another and NOT where I can see them (my well points) on the Google Earth image. So, how do folks line up their very locatlized point locations on a Google Earth visualization for their projects/clients? In addition, using the double transform to get to Projected Coordinate System (World) "WGS_1984_Web_Mercator" yields the same projected or local bounding coordinates as Projected Coordinate System (World) "WGS_1984_Web_Mercator (Auxiliary Sphere)" HOWEVER, Google Earth will not import the file "WGS_1984_Web_Mercator (Auxiliary Sphere)"  (says zero features) Why does this happen? HELP!! Nicki Cook Ni Nicki, You're caught in between our transitioning to "WGS_1984_Web_Mercator (Auxiliary Sphere)". Both it and "WGS_1984_Web_Mercator"  will have exactly the same coordinate values for the same location on the Earth. They're just different ways of emulating the coordinate system used by Bing and Google maps when they cache their data. If you access the coordinates as latitude-longitude values, they are WGS84. But what's cached is in a Mercator projection where the math supports a sphere only. For the sphere's radius, they use the semimajor axis (equatorial radius) of WGS84: 6378137.0 meters. So why are there two versions? When we originally made a definition for "Web Mercator", we had only one implementation of Mercator. It contains equations to use with a sphere or a spheroid/ellipsoid. The only way to trigger the sphere equations that are needed is to use a geographic coordinate system (GCS) based on a sphere. We built a custom WGS 1984 Major Auxiliary Sphere for it and defined "WGS_1984_Web_Mercator". Later, we added a new implementation of Mercator that supports a parameter (Auxiliary Sphere Type), which describes how to calculate a sphere's radius from a normal spheroid/ellipsoid-based GCS and use it with the projection. The projection's name is Mercator_Auxiliary_Sphere. Both versions do the same thing, force spherical math. The earlier version, using the custom GCS causes problems because you have to do a geographic (datum) transformation to it, so it's awkward. The 'new' version uses the standard WGS84 definition, so it simplifies the workflow. The version you're using hasn't been updated to support caching your data with the newer "WGS_1984_Web_Mercator (Auxiliary Sphere)". Melita ... View more

Hi Chris, this isn't really an ArcObjects question, well at least my answer isn't.  You can symbolize your layer in ArcMap based on quantities and a proportial symbol.  So if you had a count field in your line feature class defined as a numeric field, you could use that as a quantity.  Then you can set your min and max width and all that good stuff. Given Alexander's answer, I found IProportionalSymbolRenderer in the SDK help. It's in the Carto library. Melita ... View more

bzborow1;18473 wrote: Hi Guys, I'm building a search service to query unprojected attribute data, project it, and deliver the extent back to the client.  The method I'm using works unpredictably.  For are larger land parcels it re-projects perfectly find, but for really small land parcels, quarter sections, it won't reproject using the getEnvelope() method.  Can anyone offer some advice on how I might fix this problem? QUOTE] I am speculating that it could a problem with the resolution/domain values of the target spatialreference (less likely: the tolerance). Perhaps the resolution value is too large and the envelopes are collapsing. Another possibility is that the envelope, after projecting it, is distorted enough that it's collapsing. I think that would be more likely with 'long' sides--they should be densified to reflect what's happening when the data's projected, aren't. Melita ... View more

Thanks very much, Jim! I'm not desperate enough to switch browsers, but that's certainly a possibility. Melita ... View more

We are upgrading SDE from 9.3.1 to 9.3.1(sp1). We downloaded the SDE complete suite but missing the PE.pdb in particular. We could find it in the previous version (e.g. pe-sdk-bin-9.3.1-b1632-windows.zip) for both x32 and x64 platforms. The pdb is important for our development. Thank you so much and we're looking for this file urgently. Eric Eric, Will you contact me at mkennedy at esri dot com? The standard SDKs don't include the pdb (nor debug build) files. There were only two fixes for the projection engine for 9.3.1 SP1. One was for Java: if you tried to retrieve the horizion for several projections, it would crash. The other change was to improve performance when confirming whether two versions British National Grid are the same (we changed the scale factor in 9.2). Melita ... View more

Hi All, I have been trying using IBasicGeoprocessor interface's Intersect method, to create point layer at the point of intersection between the 2 layers.(one is line layer & other is polygon layer) But even after setting outputFeatureClass's shapeType property to esriGeometryPoint, type of output layer is Polygon. Could you please help me in resolving this issue. Thanking you in advance. Regards, Viji When I read the description of IBasicGeoprocessor's Intersect method, it says: [INDENT]Intersect clips the features of a line or polygon layer with features of an overlay polygon layer. The output feature class will have the attributes of both input and overlay layers. [/INDENT] It's never going to return a point feature class. As IBasicGeoprocessor says, you should use the Geoprocessing framework and tools. The Analysis toolbox has an Intersect tool that should do what you want. I haven't used it, so I don't have any sample code. There's a sample in the SDK that may help you get started: http://resources.esri.com/help/9.3/ArcGISDesktop/dotnet/43d8cc77-5193-4ca8-9878-6027782e2bbb.htm Melita ... View more

I have a table with geocoded Lat/Long Values that I want to add as point features to my map. However when I add the table and add X/Y data (Tools-Add X/Y data) the data is added to the map but the projection doesn't match up. I did compare the coordinate systems and they appear to be the same whoever the extent doesn't match up. My Shapefile with the Lat/Long Points has similar values in projected coordinates compared to the decimal degrees which leads me to believe it doesn't project? Here is an example. My Zip Code layer in decimal degrees: West: -117.597982 East: -116.080157 North: 33.511553 South: 32.530161 In projected or local coordinates: Left: 6150765.000000 Right: 6613436.500000 Top: 2129760.000000 Bottom: 1775304.125000 NAD_1983_StatePlane_California_VI_FIPS_0406_Feet And my XY layer that doesn't match: Decimal: West: -136.179977 East: -136.179964 North: 25.945595 South: 25.945576 In projected or local coordinates: Left: -117.388904 Right: -116.371055 Top: 34.517990 Bottom: 32.543795 NAD_1983_StatePlane_California_VI_FIPS_0406 also I tried about everything. If somebody could help me with this it would be GREATLY appreciated. Thank you for posting the reported data extents! The XY layer should be using a geographic coordinate system like NAD 1983, not California VI. You need to tag it with its current coordinate system. ArcMap can project it on the fly to match your other data. If you want to convert it permanently to State Plane, right click the layer in the table of contents and select Data, Export Data. In the export dialog, set it to use the data frame's coordinate system. Melita ... View more

Hello, I am writing an application in C# using the ArcGIS Engine SDK to provide ground elevation information at specified locations.  I'm using a RasterCatalog to store DTED elevation data.  To retrieve the elevation height at a desired location, I create a Surface out of the Dataset in the RasterCatalog that contains the location and then call the get_Z method, passing in the location coordinates.  From a little research I've learned that DTED elevation height information is in reference to the EGM96 geoid model of the earth.  (This model is similar to the one used for the WGS84 geoid model so I consider them interchangeable.)  This process works well but there are times when I am more interested in the the elevation above the WGS84 ellipsoid rather than above the geoid.  I've been told by ESRI representatives that vertical datum conversions are already built into the ArcGIS Engine 9.3.1 SDK in the Projection Engine but I have not been able to locate it.  Has anyone else been able to perform this conversion on a point to point basis? Thanks, cm Hi, The Projection Engine SDK (C or Java) is included with the ArcSDE SDK. The functionality is there to convert values using an EGM96 file. I've attached a C program that can convert EGM96/WGS84 geoid heights to WGS84 ellipsoid heights. Even though it says version 10 in the beginning, it works at 9.3.1. The particular vertical transformation is 10084 ("WGS_1984_To_EGM_1996_Geoid_1"). There are FORTRAN programs to access a geoid file here: http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm96/egm96.html In the past, some people have converted geoid grid file into a raster and then queried the raster for the conversion value. Melita ... View more

Same here: ArcGIS does not project correctly between ETRS-LAEA and WGS84 ArcGIS Desktop (ArcView) 9.3.1 SP1, on Windows Vista To verify the problem: go to http://www.eea.europa.eu/data-and-maps/data/urban-atlas and download the file it010l_catania.zip. This covers the town of Catania in Sicily, Italy, at aprox. 15.1E / 37.5N The data comes in an Lambert Azimuthal Equal Area projection on ETRS89. I project this into WGS84, using the ArcGIS project tool. The process succeeds without error or warnings. However, the result lies at about 4.2E / 14.4S. This is definitely wrong. I also project the dataset into WGS84, using QuantumGIS. The result lies at about 15.1E / 37.5N. This is correct. I submitted this as a support case to our local distributor, ESRI UK. Will post solution. Hello, Thank you very much for providing a link to some data. The minute I looked at the .prj file I was able to figure out what was happening. The .prj file is using these projection parameters: latitude_of_center longitude_of_center ESRI software expects latitude_of_origin central_meridian The "center" parameters aren't recognized as corresponding to latitude of origin and central meridian, so internally these two parameters have values of 0,0. That's why the longitude values are around 4E and the latitude values are around 14S. I've attached a .prj file (renamed .txt so it can be uploaded) with the ESRI version of ETRS-LAEA. Please redefine the data with that coordinate system, and I think you will find it working much better. Another issue is that we use different names in the ETRS 1989 definition which triggers "these are not the same". I hope this is useful, Melita ... View more