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.
