Latest Contributions by RyanCoodey

Ahh, I am going to look into "interoperability connections" as that could be the solution then... well once they come to Pro. Any roadmap plan for that feature? Sorry for the duplicate post over on the ideas forum too. Wanted to get the idea out there for voting. Maybe I need to change it to say "or using these interoperability connections". Thanks a lot Bruce. ... View more

Thanks for that info Bruce, that is great. Exporting data is always an option but unfortunately a manual/static one. Now just need it built in Pro for real-time joins or X/Y events . Unless there is something I am missing that Data Interoperability can do without manual involvement? ... View more

While it is a bummer there is no OLE DB or ODBC drivers for 64-bit Access connections (.accdb)... Microsoft does have a 64-bit version of the Access Database Engine (and of the Office application itself). I'm sure it is no simple task and a different approach than before, but I don't see why ESRI cannot use the 64-bit ACE drivers? The loss of Access database connectivity is HUGE. I just heard that ArcGIS Pro 2.0 was considered to have feature parity with ArcMap... but without this greatly important feature we cannot claim that ourselves. Engineers love Access (and Excel) and not sure this is a limitation we can even work around. Thanks for the consideration. ... View more

Hi Neil, Yes, we do. Since we already had these interpolated curves we thought it simplest to just generalize those (until this issue of course). Just connecting the dots from the survey though would also be too far off. Was thinking we probably need to add some logic during this interpolation to just throw away points until it deviates the max tolerance in the either X, Y or Z space. We still need to hold onto the high precision line as well though so would have to output two versions at this point. Or we could probably just build our own FME job to do something like this. Start with the first vertex then loop through all of them until it is greater than the tolerance along any axis. Then hold on to that coordinate and do the same looping to the next. And so on. That sound like a viable option? Thanks much! ... View more

Dan, other than playing with Pro for about 10 minutes, I cannot say I have worked with it much. It had crossed my mind to check it out for this current issue... but thought it probably still used the same GP tools and calculations. If that is not the case, I will certainly check it out more? FYI, the boreholes are not perfectly straight. Part of the problem with the generalize not obeying Zs is that it is straightening them out too much and deviating too far from the original line. Thanks for all the help! ... View more

Dan, The majority of the lines are not straight nor do they follow any pattern. The lines are for wellbores starting at the surface and winding their way between geologic structures and other wellbores to a point thousands of feet below the surface. The means of getting there is manual and varies for each. Abdullah, The elevations are subsurface and come from survey points. A minimum curvature algorithm is used to closely generate the line between survey points. So a DEM wont work for us in this situation. Thanks a lot guys! ... View more

Hi Dan, thanks for that information. We are basically after simplification based on proximity. We have ~60,000 3D lines each varying from 1,500 to 6,000 feet long. Each of these lines has a vertex at each foot along it, that's a lot! So after running the current generalize tool, a line might go from 2,000 vertices to 100. We just need the line to stay within a tolerance of about 1/2 a foot. Our drivers for this are:      1. The performance on this dataset in ArcMap and ArcScene is tremendously better.      2. We need to intersect these 3D lines with 3D multipatchs... that intersection GP tool works great but takes many, many hours when run on the non-generalized dataset. The multipatches that are intersecting these lines change often so we have a nightly job to recalculate the intersections. That's our reasoning for this at least. Thanks again for the help and if you or anyone might have any recommendations to solve this issue, that would be much appreciated. ... View more

Morten beat me to it but to add a little more info, after talking with support for a few weeks about this we got a ticket assigned (NIM104466: ArcGISTiledLayer does not display data when zooming in beyond the minimum resolution defined by the service) With this response: "The change that was introduced was to honor the visible scale range as defined by the service. Currently the only way to handle this is by changing the settings on the service. We understand that this not a workable solution for many customers. I just got out of a meeting with Product Management and they are aware of this and the current plan is to target this for the 10.2.4 release of the WPF SDK that we should see later this year." They also mentioned there was no gurantee we would see it in 10.2.4, but that is their current goal. Thanks a lot ESRI for addressing this issue for us! It is much appriciated. ... View more

Just wanted to check in and see if this was ever implemented? We are not really having the "NoData" problem anymore but just that the imagery disappears to the white background when zoomed way in now as mentioned in this Silverlight thread: http://forums.arcgis.com/threads/106745-3.2-And-ArcGISTiledMapServiceLayer-MinimumResolution-Property. Any known workarounds for this in the WPF API? Thanks much. ... View more