Latest Contributions by MelitaKennedy

Unfortunately, I know nothing about Arcade except that it's an expression language. I just looked through our Arcade website and some references to Arcade on the Javascript API pages. It doesn't look like the functions/methods are there to take apart a feature or even to change the coordinate system/projection engine.  Does the feature service support only 2264? 2264, NAD83 NC State Plane (US survey feet), uses Lambert conformal conic (LCC) with these parameters: False Easting:2000000.002616666 (odd number due to being converted from a truncated value in meters) False Northing:0.0  Central Meridian:-79.0 Standard Parallel 1:34.33333333333333 Standard Parallel 2:36.16666666666667 Latitude of Origin:33.75 It's on the GRS80 ellipsoid: semimajor axis: 6378137.0 flattening: 1.0/298.257222101 LCC is not an easy projection to implement. You need the ellipsoidal version of the equations. One place to find them is John P. Snyder's Map Projections: A Working Manual, available in PDF form from this USGS site: Map projections: A working manual  ... View more

The one I found is very similar.  ... View more

The attachment didn't make it. If I remember correctly, you have to upload it and then attach it to the post. ... View more

I would swap the state plane northing and easting values. You want the same x,y x,y ordering between the two sets of coordinates. Optionally, add commas between all the values. ... View more

I hunted around a bit more and found some documents from 2005, which state that the geodetic reference net is based on ETRS89. If the KOSREF projected coordinates are based on ETRS89, they still don't make sense to me, because they shouldn't be that different from WGS84 coordinates. ... View more

Hi Ron,  This is very interesting. I only found a little bit of information on KOSREF except that another name maybe KOSOVAREF and that the projected coordinate reference system is the same as EPSG's 3909, MGI 1901 / Balkans 7. The projection parameters are: Central meridian: 21.0 Latitude of origin: 0.0 Scale factor: 0.9999 False easting: 7500000.0 False northing: 0.0 I assume that the geographic coordinate reference system is MGI AKA MGI 1901, but the offsets between your KOSREF and WGS84 "GK zone 7" coordinates are too small compared to when I convert between MGI and WGS84 using any of the geographic/datum transformations.  I haven't been able to confirm whether KOSREF is on MGI (which uses Bessel 1841 ellipsoid) or not.  Because your offsets are between two projected coordinate reference systems, there isn't a direct way to model the differences. You might be able to do this by creating two projected CRS, and modifying the false easting and false northing parameters of one to incorporate the offsets. Another method could be to use the Create Custom Geographic Transformation tool. There is a Geographic 2D Offset method. The offsets are in arc-seconds. I unprojected both datasets, assuming that the KOSREF is on MGI 1901.                  WGS84 longitude WGS84 latitude KOSREF longitude KOSREF latitude longitude difference in seconds latitude difference in seconds 20.9973292100229 42.5403926048346 20.9973570639586 42.5574121053765 0.10027416851415 61.2702019508362 20.9965745282358 42.5377096561408 20.9966020849491 42.5547288707077 0.09920416787566 61.2691724408421 20.9948579691214 42.5377906200380 20.9948848524508 42.5548098436273 0.09677998583015 61.2692049214587 20.9949186281643 42.5404015264134 20.9949455363440 42.5574210284567 0.09686944692788 61.2702073558950 The offsets aren't as uniform as the projected versions (which seem suspicious to me actually). You could average these and use them.  Melita ... View more

I don't know of a way in the main/core software. If you have access to the Data Interoperability Extension or FME, they might be able to do it by converting the data into a GeoMedia format. If you have any examples of the contents of a .csf file, maybe it's possible for me to show how they could be converted. Melita  ... View more

Yes, geodesic by default. That actually makes sense because of the wide use of Web Mercator. You don't want to use that. NearMe, because it *should* be used for very local calculations can get away with using whatever coordinate system is being used. ... View more

Hi Bill and Matt,  I'm not sure this needs a separate geographic coordinate system definition, but could be covered by allowing data to be tagged with the 2017.5 epoch date. I have entered an internal issue and will discuss it with Kevin M. Kelly. At least, that's my current thinking based on these statements here:  It is rigorously aligned to the current definition of the National Spatial Reference System (NSRS) through a set of coordinate transformations from ITRF2014 to NAD83(2011), published by the NOAA/NOS National Geodetic Survey (NGS). CSRS Epoch 2017.50(NAD83) replaces the previous “CSRS Epoch 2011.00 ITRF2005 NAD83(NSRS2007)” datum that included coordinates for 830 CSRN stations. Geoid heights from the latest NGS-published model, GEOID12B, have been applied to develop Derived California Orthometric Heights for all of the CSRN stations, in accordance with PRC §§8890-8902. Melita ... View more

I don't think there is anything. The Lining Up Data in ArcGIS book by Margaret Maher is getting a refresher this year but still has only very basic ArcGIS Pro information.  There's been some talk in-house of doing something. Part of the problem is finding someone who has the time and expertise.  Melita ... View more

Hi Piper, The software is not designed to handle a full path. It's designed to look for a set of data, structured in a certain way. Some methods are even designed to look for certain folders (NTv2, NADCON, HARN, the file-based vertical methods). Melita ... View more

Hi Paul,  You've managed to put together a workflow that has several issues! The first is that ellipsoidal heights need to use the same datum as the geographic coordinate system.  You're mixing a geographic coordinate system WGS 1984 with vertical NAD 1983 (2011) ellipsoidal heights.  The second issue is converting to NAVD88 (US survey feet). There's no direct transformation between NAD 1983 (2011) ellipsoidal heights and NAVD88 (US survey feet). There are transformations between NGVD29 and NAVD88 (US feet) so the path might be to convert WGS 1984 ellipsoidal heights to NAD 1983 (2011) + ellipsoidal heights. Then NAD 1983 (2011) + ellipsoidal heights to NAD 1983 (2011) + NAVD88 (meters) using the GEOID12B model. To get the US feet however, you would then have to convert to NGVD29, then back to NAVD88 (US survey feet). Unfortunately, that path is 1 geographic/datum transformation plus 3 vertical transformations. Right now, we're limited a path to 4 steps, of which up to 2 can be geographic tfm and 2 can be vertical tfm. You may need to do this in two conversions.  I think you will also need to do the second portion (NAVD88 to NGVD29 to NAVD88 (US ft) ) in ArcGIS Pro, but not in ArcGIS Desktop. The latter is using the hvtdefaults.json file which is installed in the pedata folder in the core software install. I actually tried to add a few entries last week to it, but could never get them to work properly. ArcGIS Pro is using a function to find paths and is much more flexible. The json file hasn't been updated with newer transformations. Melita ... View more

Depending on which version you're using, you could create a fishnet for one or the other grid (or both). You might have to do some attribute or labeling work as it would get projected to whatever the data frame's coordinate system is. ... View more