can geofence in geoevent support WKT
Hello Jack -
Have you tried leaving the WKID property unspecified (deleting the default 4326 value from the field) and then importing feature records from a feature service to establish geofences?
I don't have a feature set or feature service I can easily use to test this. Everything I have is associated with a well-known coordinate system, so the feature service's spatial reference has an associated WKID. However, I can tell you that if you delete all existing geofences, then stop and restart GeoEvent Server to force the in-memory quad-tree structure to be destroyed ... the first geofences you import should establish the spatial reference for all geofences loaded into the registry. Known limitations are that you cannot have geofences associated with more than one spatial reference, and you have to both delete existing geofences and restart GeoEvent Server if you want to change the spatial reference being used for your geofences.
I do not think that it is possible to specify WKT when importing feature records as geofences to have GeoEvent Server maintain geometries with something other than a well-known coordinate system. The WKID parameter is intended to allow you to specify that GeoEvent should project the feature records it polls from the feature service for you, on-the-fly, to a well-known coordinate system, as the feature records are imported.
I would be interested to observe the behavior if the spatial reference of the feature service used to import the feature records had no associated WKID. If the default value 4326 is removed, I'll bet that GeoEvent will fail-over and project the geometries to 4326 anyway (from the custom spatial reference).
You should be able to see exactly what the geometry is for a geofence, once it has been imported, by clicking the pencil icon on the Site > GeoFences page to edit the geofence. The geofence's geometry will display as a JSON String which should include the spatial reference:
- RJ
