Geomery Querying on Envelopes

[CarlosColón-Maldonado]

Greetings,

I am looking for functionality to determine whether geometries are located within the regions and/or areas of interest of a map.

Browsing throught the API, I noticed that Point and MultiPoint geometry-type objects have methods to query a given Envelope object to obtain an "axis aligned bounding box of the geometry." I happen to find this statement from the Android API since the Java API lacks detailed documentation as of this post, and I am assuming the function's intent is the same.

Could someone explain here what are best uses of this function, and if it can be used to determine if a geometry is in fact contained within the boundaries of the given Envelope? I would welcome a better approach as well.

Thanks, again. I am glad to be working with your tools!

[EricBader]

Hi Carlos:

Have you looked at the GeometryEngine object? It exists in both JavaSE and Android SDKs.

Here, you'll find the "within" method that determins if one geometry is within another geometry.

Is this what you are looking for?

I hope this helps.

[CarlosColón-Maldonado]

Hi Carlos:

Have you looked at the GeometryEngine object? It exists in both JavaSE and Android SDKs.

Here, you'll find the "within" method that determines if one geometry is within another geometry.

Is this what you are looking for?

I hope this helps.

Merry Christmas, Eric,

Indeed, I have. I actually discovered this functionality also found in the Graphic object. But, if I choose to use it, it would mean that I have to access and track every Graphic object the message processor creates, obviously also by layer, in order to make this calculation. Is that good practice in using the API? I would imagine that functionality to select symbols contained in the message group layer would be in the layer since it is also used to create and highlight them as well (or at least is the plan in the next release).

Please, advice.

[EricBader · Accepted solution]

Merry Christmas to you as well, Carlos!

Ah. Forgive me. I see what you are asking for now, I think.
I was assuming you needed a one-time check on a single geometry at a time.

You need something that determines this condition on a collection of geometries? All at one time?

Please confirm.

If so, you may need to look at the GeometryService, which takes an array of input geometries for comparison, and does the relationship operation in a one-time call.

If you cannot use a remote service in your application, another approach could be to use a geoprocessing task from a GP package, locally, to take an array of geometries as input.

I may not be on the right track as to what you are asking. I apologize if that is the case.

Thanks!

[CarlosColón-Maldonado]

I like the idea of a local geoprocessing task from a GP package that takes an array of geometries as input for making these determinations. But that means that I do have to manage and track the geometries for all graphic layers the MPC generates via the message group layer's processor, doesn't it?

I merely want to know if that is good practice because my MPC's perception has been to allow its message group layer to manage (create, update and delete) the military symbols you ask it to display. The part of CRUD that's not clear to me is the reading/retrieving (R) part. Is is good practice to access each dynamically-generated layer off the message group layer to access its containing geometries and then pass them to a task that also takes a referencing point, geometry for region, or envelope for area of interest, to determine which of them are found within its boundaries? I don't see another way to retrieve them.

I should add that the geometries being queried against are contained in graphic layers and not in geodatabases, so I'm not sure if this is even possible using a geoprocessing function. Also, there doesn't appear to be a GeoprocessingService type in Java API, but only on web and mobile APIs such as WPF or Android. Will it be in the next release?

It appears to be a viable solution, but I want to make sure I won't cause any potential performance efficiency or thread-raising issues later.