nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Has anyone had problems with Construct Geometry from Fields?

KylePerri

For some reason when I try using construct geometry from fields the drop down for the x, y, and z values don't populate. It is unable to read the fields from my GeoEvent definitions, but other dropdowns work. For instance, I was able to create the geometry using a field calculator processor. I haven't tried all input connectors, but I saw it on the watch a folder for files connector and the poll a website for JSON connector. Has anyone else had this issue and know a solution?

Encuentra más publicaciones etiquetadas con

Accepted answers

All comments

DanielCota1

Hi Kyle Perri‌

Is this nested JSON by any chance? Can you provide the configuration xml file or a screenshot of the input connector config?

KylePerri

No, the JSON isn't nested and I have my lat and long set to double in the geoevent definition.

DanielCota1

Kyle Perri‌

Can you manually input the field names and see if it takes and allows the geometry to be constructed?

KylePerri

When I do that no data goes through and I get errors in the logs because it can't find the fields.

BrianLomas

Was the GE definition created by GE or did you manually create it? I've had a lot more success having GE create the definition than manually doing it. Also, can you share an example of the JSON?

KylePerri

I tried both ways, no luck. I was just using this API for testing purposes: https://api.wheretheiss.at/v1/satellites

JSON looks like this:

[{"name":"iss","id":25544}]

DanielCota1

Hi Kyle Perri‌,

If that truly is the JSON you are working with, then it would be expected that Geoevent is unable to construct geometry from it. There are no geometry fields to work with. Meaning, there are no X/Y or Lat/Lon fields that Geoevent would be able to read and create a geometry field from.

I have worked with that API before, and I have found that using this endpoint works much better for testing:

https://api.wheretheiss.at/v1/satellites/25544

As you see, it includes a latitude and longitude field that you can specify in the input connector configuration.

Keep in mind, however, that this API is known to intermittently go down and requests to certain endpoints sometimes result in a "Too many requests" error. Aside from that, it should work better for your testing.

If you are interested, you can also try using http://api.open-notify.org/iss-now.json for your GE testing. I have not personally experienced any outage issues with this one. However, this JSON is nested, so be mindful of that when specifying the JSON Object.

Hope this helps!

-Daniel

KylePerri

Yeah and that's fine I understand that it doesn't have lat/long, but it doesn't even have any values in the dropdown. You'd think GeoEvent would at least populate the dropdown with values that could be lat/long. For instance, the id is a double in the field definition, so it should show up in the dropdown. I point to that link because my actual data is sensitive and can't be shared, but that data does have lat/long values and still nothing in the dropdown.

DanielCota1

Gregory Christakos‌ RJ Sunderman‌

Do you guys have an idea as to why this could be? Does GE only populate the field options in the dropdown based on field type? Tags?

I just checked on my GE Server and see something similar. When I click on the dropdown, I see field options coming from the OOTB "incident" definition and not the definition I have set for the input. I have always manually typed out the field names for the X and Y parameters and it has never given me an issue, so I did not really put much thought into it.

Maybe we are just missing something?

GregoryChristakos

Hi Daniel Cota‌

The construct geometry property fields are entirely dependent on the GeoEvent Definition chosen by the user. Let me explain through a few scenarios.

By default, the "Poll an External Website for JSON" input connector has the default "Create GeoEvent Definition" property set to Yes. This means that the user is prompted to provide a name for what will be their eventual GeoEvent Definition. Technically, the fields do not yet exist since the definition itself does not yet exist. Should the user also choose to 'construct geometry from fields' from what is otherwise a non-existent GeoEvent Definition in this hypothetical situation, they are only going to be presented with fields/tags from 1) an already existing GeoEvent Definition that is 2) alphabetically the first in the list of already existing GeoEvent Definitions. In a scenario where a user is working with a fresh install of ArcGIS GeoEvent Server, this would be the "Incident" GeoEvent Definition (& its fields/tags) since it precedes the TrackGap GeoEvent Definition also installed with the product (I before T).

In another example, lets say the user already has several GeoEvent Definitions made however they still choose enable "Create GeoEvent Definition" and "Construct Geometry from Fields". If there's already an existing GeoEvent Definition under the name "Airplanes", then by default you're only going to see the fields/tags from the Airplanes GeoEvent Definition since it is first alphabetically.

If you wanted to tinker with this to get a clearer idea of what I am talking about, you can set "Create GeoEvent Definition" to No, select a different existing GeoEvent Definition (e.g. anything that isn't Incident), set "Create GeoEvent Definition" back to yes, and then observe what fields are made available for the Construct Geometry From Fields sub-properties (X, Y, Z). While this is certainly an odd exercise, I share it with you to illustrate the fact that "Create GeoEvent Definition" (set to Yes) in unison with "Construct Geometry From Fields" (set to Yes) makes the most sense when you provide the typed out field names based on the expected inbound schema. For example, I might poll https://api.wheretheiss.at/v1/satellites/25544, set the "Create GeoEvent Definition" to "Yes", set "Construct Geometry From Fields", to "Yes", and then for X enter "longitude" (no quotes), and for Y "latitude" (no quotes). Or to make things more simple, I would have GeoEvent Server poll the data, create the initial GeoEvent Definition, and then go back into the input settings here to have it construct geometry from the fields of the GeoEvent Definition it just created and understands (granted you might need to change the name of the fields).

Where I might take more advantage of the drop down fields/tags is when I set "Create GeoEvent Definition" to No, select the correct GeoEvent Definition for the inbound records, and then choose the appropriate X, Y, and Z fields associated with the GeoEvent Definition I had specified.

In no scenario are you going to see the X, Y, and Z geometry fields show all possible fields from every single GeoEvent Definition. Lastly, I should add that only certain field data types are going to show when constructing geometry. For example, a field with a data type of "date" isn't going to be an option since coordinates cannot be expressed as dates. While I hope this helps clarify things, let me know if you have any further questions.

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.