Latest Contributions by KyleGonterwitz3

Good idea.  To do this you will want to track edit changes and ensure your portal group security is working with the change tracking, and yes protect your default and manage LRS Locks in event editor with a lockroot subversion from default and conflict prevention enabled in the ALRS Settings.  I would configure event editor applicatons, secured and delivered to members assigned to portal groups, and customize the cartographic content to facilitate the workflow to the maximum extent possible.  Also configure the event editor with full ability of the editor to create a version, post and reconcile, manage locks, and delete a version all with event editor buttons.  What I do is publish the services with a shared user that is only used for publishing services, not a data owner user or an active directory user but a named user in the database with privileges set for editing event data in versions.  I think in a multi-user environment you would definitely want to have at least a version per user, sometimes more depending on the situation and the number of EE configurations you set up.  It is possible to configure event editor using portal maps that can combine read-only services with the ALRS service, but snapping in the Event Editor might not work on those non-alrs services.  You can also probably add read-only connections when publishing the service to enable the reference layers to support snapping, maybe.   For our installation it was difficult to get the federated portal all set exactly how it had to be for ADFS users and conflict prevention to work but now that we have that figured out I wouldn't want to do it any other way, and it appears this approach is going to work well to achieve your goal, and mine too, of supporting program areas in such a way that they can utilize the event editor and spread the workload horizontally into the agency. ... View more

not quite like that... are you using append events?   ... View more

also commented out here is a half baked process to derive a statewide state highway network from the county network.  I think we are working on altering the approach we are taking at that, but the process can be added with just a few additional steps in this process if those steps are done in just the right sequence.  I think we currently are ironing out our expectations and requirements for the data of this derivation process to serve interfaces, and we are thinking of adding an event to maintain the state network history as derived from the county network.   ... View more

I wanted to share an update to our scripted process, now we have included a point event for flagging opposite directions of inventory primary routes on dual carriagway.  By putting the event flag on the real primary noninventory route side, we then adjust the route concurrency table on the segment we flag, overriding the default concurrency rules that would have the inventory direction in both directions across the right of way for two different routes.  An example of this in KAnsas is where US54 intersects US69 and they run opposite on dual carrigway north of Fort Scott Kansas.  For us, US54 is the primary inventory route, so we flag US54 non inventory and alter US69 inventory to turn into US54 noninventory. rather than paste all that code again, here is a link to the code on github: pydev106/GeodbMaintenanceQC.py at master · KDOTGIS/pydev106 · GitHub  another important step I want to point out in our proess is this other script to copy metadata updates beween dev, test, prod, transactional, and publiction environments, pydev106/CopyMetadata.py at master · KDOTGIS/pydev106 · GitHub  ... View more