|
POST
|
Hi Diane, You were trying a bunch of different things which is what I meant by "workflows." This line: new Point(172.5322, -43.4892, new SpatialReference(102021)); should be new Point(172.5322, -43.4892, new SpatialReference(4326)); Then the point needs to be projected using geometry server to 102021.
... View more
02-07-2017
10:37 AM
|
0
|
2
|
1205
|
|
POST
|
Using Project is the right idea. You need to identify the incoming points as 4326, then Project them to 102021. If you can give a sample input point, plus its output coordinates for various workflows, we might be able to tell what's happening. Melita
... View more
02-06-2017
03:54 PM
|
1
|
4
|
1205
|
|
IDEA
|
It's fine. I'm not up on the math, but there's a mention of an authalic sphere, so my guess is that Karney is doing a similar solve-triangles but on a equal surface area sphere. I think it's probably more accurate than Jenness. When my colleague was looking at doing direct area calculation on an ellipsoid, he couldn't get a stable implementation. We're using a mix of geodesic calculations and ellipsoid-based equal area projections. Greg Hollard Was the data in a pcs when you ran the planar getArea calculation? If so, what was it? If it wasn't equal area, could you run it again for me? Could you explain further about the legal ramifications? Is there legislation that Jenness's method must be used? Or that the same method used previously must be used? Or? Thank you! Melita
... View more
01-26-2017
01:43 PM
|
0
|
1
|
3767
|
|
IDEA
|
When I see spherical as part of the name, I assume that a sphere is being used as the model of the Earth. If that's the case, I would expect different results. According to the help document for his Tools for Graphics and Shapes, the tool converts a spheroid/ellipsoid to a sphere of equal volume (p73). To calculate areas, I would expect a conversion to an authalic sphere instead--same surface area.
... View more
01-25-2017
09:51 AM
|
0
|
1
|
3767
|
|
POST
|
Hmmm, somehow the extent is screwed up. Maybe an empty row or a row with bad values?
... View more
01-25-2017
08:36 AM
|
0
|
1
|
3096
|
|
POST
|
I don't know the answer, but the new coordinate system names are closer to (but not exactly) the EPSG names rather than the Esri names. The change in the false easting/northing precision matches as well. The change in the WKT definition could be enough that a transformation is no longer being found between say NAD83 HARN and WGS84. We have the EPSG names as synonyms but don't have the "check-the-EPSG-names" enabled in our string/object equality functions. Anyway, this "EPSG" name is not close enough to the canonical EPSG name to trigger the "these-are-the-same" check even if it was enabled.. I already asked AGOL people once if there was a change in the December 2016 update that could have affected coordinate systems/transformations, but they said no. If you've got a problem that appeared in mid- to late December, I would contact technical support or your distributor about it. Kevin, the WKID for NAD_1983_HARN_StatePlane_Florida_East_FIPS_0901_Feet is 85 on the spatialreference.org website. That is not an official authority website. In Esri, it's EPSG:2881, just like the one in the EPSG registry. Melita
... View more
01-24-2017
02:27 PM
|
1
|
0
|
3561
|
|
POST
|
Sometimes vangelo-esristaff is here, but I can almost guarantee he'll say to contact technical support. Was the geodatabase upgraded? Is it at 10.3 (check in Catalog)? Are you using direct connections? How's the data stored in Oracle? SDO, SDE binary, ST_geometry?
... View more
01-24-2017
10:58 AM
|
0
|
7
|
4701
|
|
POST
|
Any chance of posting the data--or at least one "good" row and one "bad" row? I would expect that there's something in the new rows--a leading space in a field, a control character, something. Melita
... View more
01-23-2017
12:14 PM
|
0
|
3
|
3096
|
|
POST
|
Hi Jeff, If you have a point in lat/lon (preferably the center), you could use the "Local" projection. It takes a center point in lat/lon, scale factor, azimuth (from geodetic North), false easting/northing. It's the same as orthographic, but supports an ellipsoid. Melita
... View more
01-20-2017
11:41 AM
|
0
|
1
|
2002
|
|
POST
|
I forwarded a link to the thread to the tool owner who will fix the documentation. He plans to look at removing the dependency on the Frequency tool as well. We apologize for the mistake. Melita edit: added sentence about removing tool dependency.
... View more
01-20-2017
11:29 AM
|
1
|
2
|
1775
|
|
POST
|
Yes, it's possible. I don't know about the geometry engine bugs (different team). If you post or send me (mkennedy at esri) the input / output values, I can check them. Melita
... View more
01-19-2017
10:28 AM
|
0
|
0
|
2657
|
|
POST
|
Can you check your basemaps against other data--particularly NAD83/NAD83(2011)-based data? Let's say your NAD83 data is really 2011, and should be offset from "true" WGS84/ITRF coordinates. I think many basemaps and other datasets, even if they say they're WGS84 (ITRF), are probably NAD83 (and/or 2011)-based. So maybe try to compare your data with some other state data (Lidar) to see how it lines up?
... View more
01-17-2017
01:59 PM
|
1
|
0
|
3276
|
|
POST
|
Nope, feel free to do so. You might put a note into the data's metadata discussing the issue for the future.
... View more
01-17-2017
11:50 AM
|
1
|
2
|
3276
|
|
POST
|
After looking at the data extents, did you project the buildings data to the new coordinate system or use the data's property page to change the coordinate system? The latter method updates the metadata only, so the coordinates are still georeferenced to the original coordinate system. The Y values of the extent are too small to be in ITM. They look more like Palestine Grid (either using Cassini or TM).
... View more
01-16-2017
01:02 PM
|
0
|
0
|
2160
|
|
POST
|
Possibly, you may need to apply a transformation. You also may want to set a transformation before you publish the service so that you know which transformation is being used. It depends on the data. Some data, you can get away with calling WGS84 and NAD83 equivalent, so you want to use NAD_1983_To_WGS_1984_1 (parameters are zeroes). There are certain places where a default transformation is used and currently that one is NAD_1983_To_WGS_1984_5 (parameters are not zeroes) because NAD83 (later than the original 1986 version) and WGS84 are not coincident are now around 1 m apart in CONUS (more elsewhere). The "default" transformation would be used in cases where a 'client' like ArcMap says "gimme the data in B" where the service was published in A. To save on processing and display time, the server reprojects the service data to B and sends it. You might run some checks in ArcMap--is the base map still listed as 3857? What happens if you set either of the above transformations in the map?
... View more
01-13-2017
12:59 PM
|
1
|
4
|
3276
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | Wednesday | |
| 1 | 01-31-2014 09:23 AM | |
| 4 | 01-18-2026 04:30 PM | |
| 1 | 01-16-2026 10:03 AM | |
| 2 | 12-02-2025 08:06 AM |