There are cases where we want to store spatial information in a table's non-spatial fields and create dynamic event layers on that information.
We currently use the existing event layer types with great success: XY event layers and linear referencing route event layers. Those existing event layers are very powerful tools...and we want more!
- Polyline event layers
- WKT example: (30 10, 10 30, 40 40)
- Polygon event layers
- WKT example: ((30 10, 40 40, 20 40, 10 20, 30 10))
- Multi-part point event layers
- WKT example: (10 40, 40 30, 20 20, 30 10)
Use cases:
- Use a multipoint WKT field in a non-spatial table to create an event layer — for scenarios we don't have the option of converting the table to a FC, such as an external database.
- Or, a WKT field (polyline, polygon, or multipoint) in an existing FC. We can't have multiple geometry columns in a FC, so we'd store the information in a non-spatial text field instead, and create an event layer on it.
- Lots more...
Performance:
My experience has been that event layers are surprisingly fast:
Why are XY event layers so fast?
The XY event layer is generated on the client-side after all required library/data has been downloaded on the client machine, therefore there is no client-server connection required. It is also fast because it is generated from the Computer's RAM. In contrast, if you are querying geometry from DB, a client-server connection is required and a query is performed on the DB server which causes the latency.
So, if XY event layers are fast (linear referencing route event layers are reasonably fast too), then hopefully that high performance would translate to line/polygon/multipoints as well.
Alternatives:
We're aware that there are other ways to calculate geometries, but they have downsides:
- ST_GEOMETRY views: The ST_GEOEMTRY constructor/function is far too slow for generating geometries on-the-fly. In a test, an XY event layer on 10,000 rows loaded in the map instantly, whereas an ST_GEOMETRY point view took 10-20 seconds using the same data. So ST_GEOMETRY isn't a realistic option.
- Attribute rules to populate a separate FC: That would likely work, but would require extra FCs to manage. Our EGDB is already quite big/complicated, so we want to avoid that extra complexity if we can help it. Also, attribute rules wouldn't be applicable if the table was in an external database. So, something like dynamic event layers would be preferred.
- Database triggers to populate a separate FC: Similar to the attribute rule option, triggers might work, but would require extra FCs to manage, aren't applicable if the table is in an external DB, and aren't really supported by Esri either. Not to mention the fact that versioning makes things extra complicated/risky/unsupported.
- As far as I know, there aren't any geoprocessing tools that can create a FC from WKT. And even if there were, the FC wouldn't be dynamic, so that's not what we're looking for...and scheduled jobs to recreate FCs aren't quite what we want either. The same limitations apply to Python scripts.
Limitations/Tradeoffs:
We're aware that there could be limitations for the proposed event layer types, such as:
- The event layers would be more complicated than a basic XY event layer. So, for large datasets, or features with lots of points, performance might be slower than we'd like. But users are aware that event layers have their limits by nature of being dynamic, and would plan accordingly.
- It's also worth mentioning that linear referencing event layers are reasonably fast. They're based on lines, so maybe other complex geometry types like lines/polygons/multipoints would perform well too.
- We would need to populate the WKT field with spatial information...one way or another...which would require custom code. But we could live with that. There are lots of different ways of calculating a field in ArcGIS...so one of the options should work. And, in some cases, the field might even come pre-populated if the table comes from an external system.
Summary:
Having event layer functionality for lines, polygons, and multi-part points could be very handy. We already have event layers for points and linear referencing lines, why not give us event layers for the other geometry types too?
