Latest Contributions by JonHall

At the bottom of the GIS Data Model standard page, STA-006.1-2018, the download links have been posted for the 11/20/2019 release of an empty file geodatabase, "NG911_GIS_TEMPLATE_FILES_20191120.zip",  and a reference document "NENA-REF-006.1-2020.pdf" https://www.nena.org/page/NG911GISDataModel ... View more

Katy- STA-006.1 is the final, published version 1 schema definition. A version 2 update to the GIS Data Model schema is planned, future work, as NENA's NG9-1-1 "i3" architecture matures. The Public Review version of "NENA GIS Data Template Zip Files", published August 27, 2019, were a "proposed" geodatabase implementation of the "final" version 1 schema definition.  After the Public Review comments were discussed, a few final changes were made in the file geodatabase implementation, metadata was updated, and the work group wrapped-up last week. NENA should publish an announcement soon, when the "final" geodatabase implementation of the STA-006.1 schema is available to download from National Emergency Number Association   ... View more

Bill, I don't understand your question, contact me offline ... View more

 GIS Data Templates Available for Public Review Aug 27, 2019 3:38 PM NENA's GIS Template Working Group is pleased to announce the availability of its DRAFT GIS data templates for public review and consideration.  The GIS templates are a direct interpretation of the NG9-1-1 GIS Data Model (NENA-STA-006.1-2018).  The primary purpose of the GIS data templates is as a common data structure for data exchange between agencies or their vendors.  As best stated by NENA-STA-006.1-2018, "It is not expected that every entity will use the GIS data model described within this standard (NENA-STA-006.1-2018) for its day-to-day internal use and maintenance but it is expected that each entity will be capable of exporting their internal GIS data model into a given GIS file format that complies with this standard as frequently as may be necessary." It is the goal of the GIS Data Template Working Group to provide a GIS Template for entities to use in order to fully, and consistently, meet this requirement. Before the GIS Template Working Group publishes its final deliverables, it is interested in hearing from any agency willing to extract, transform, or load (ETL) their GIS data into one of these templates.  The working group is particularly interested in hearing about any complications, challenges, limitations or other problems associated with the ETL process. There are 4 files provided as part of this public review period and are combined into the zip file located here. First, two scripts the GIS Template Working Group used to create the GIS data templates are being provided (i.e. .sql & .py).  While the scripts are not, technically speaking, the official deliverables of the working group, the working group felt it was important to be open about how the GIS template deliverables were created. Second, two GIS data template structures are being provided.  One data template structure is provided as a Esri File Geodatabase which the user will need to first extract.  The other data template structure is provided as a PostgreSQL database dump file. The GIS Template Working Group would appreciate your review by Friday the 13th of September.  Should you have any questions, please contact Jason Horning. ... View more

The file geodatabase schema, created with arcpy script, defining the fields and domains, has been loaded into enterprise SDE on SQL Server. ... View more

Right, Randy, that's the behavior I expected, but ArcMap throws that error message, and no null value is saved in the field. ... View more

Randy, thanks for the response. Yes, "I don't think it is possible to have a coded value domain where" the code is an empty string.  That's why I posted this question. ESRI hasn't documented whether it is or isn't possible, but trial and error indicates that it's not. I suspect that our workgroup has mis-used the isNullable option, with the intention of allowing empty values. A field that isNullable can be deleted from the attribute table.  The field is REQUIRED, whether it contains values, or not. My understanding is that a database null value is quite different than storing a 6-characer string, "<Null>", which is what ESRI's ArcMap table user interface is attempting, when it throws the error that "This field will only store string values with up to 2 character(s)".  I may start a separate thread on that topic, but hate wasting time spitting into the wind, complaining about ESRI software, unless it's a stupid-user-problem and I might learn the error of my ways from the GIS community.  If I solve either issue, I'll post the workaround or solution. ... View more

"One other question ...rebuild index BEFORE you run the Analyze Datasets?  ...run in the other order, directly after compressing the database"? This is an old question, really 2 or 3 questions. I've been refreshing my memory on this topic. Please correct me if I'm wrong. My answer applies only to SQL Server DBMS. First, I've had DBAs argue that Analyze Datasets (update statistics) is unnecessary, because SQL Server updates statistics automatically. As I recall, the answer is that SQL Server may not do it automatically right away, and you may need the possibly improved query performance from update stats sooner than later. Like during COMPRESS. As I recall, the purpose of rebuilding indexes before analyze datasets (update statistics) is that rebuilt indexes are then considered as part of the analysis of best query performance.  If your COMPRESS runs fast anyway, you may waste more time Analyzing than you save in Compress speed. , and may actually waste time running Analyze. As I recall, YES, you should definitely Rebuild Indexes and Analyze Datasets (again, or only) after running Compress. COMPRESS changes the Base tables, and therefore your indexes and statistics may be stale. ... View more

Yes ... View more

After a freaking hour plus, I have determined that ArcGIS Desktop 10.6.1 "Features To JSON" with the GEOJSON option ONLY WORKS with SHAPEFILE INPUT. Come on, ESRI....  "Features To JSON" repeatedly crashed, after output for the first few polygons, on the 4th or 5th polygon geometry, WHEN USING a FILE GEODATABASE OR ARCSDE polygon FEATURECLASS INPUT. I tested with 3 or 4 different polygon featureclasses that were in WGS84, whether or not within a featuredataset, in FGDB or SDE, no matter, it crashed every time with a useless "99999" err msg. The log file was also useless. Clearly it was choking when reading geometry. Copy the same featureclasses into shapefiles, and the GEOJSON output option works fine. ESRI, I can't believe your code doesn't support FGDB or SDE, only supports legacy shapefiles as input. And you want me to move to Pro...LMFAO I'm sorry this is in the wrong forum... ... View more

Kasey, Peter, all- FYI Last month, NENA's Data Structures Committee spun-off a GIS-data-model-template workgroup to publish a Python script that creates a new File GDB with the schema specified in NENA-STA-006.1  After looking at contributions by Michael Fashoway , Lake County, and others, the workgroup chose to build upon a Python script developed in the state of Washington (my apologies for not recalling the GIS folks who deserve credit! they will  be acknowledged by NENA in the published info doc).  The work group may post the Python script for public comment in a few weeks or months, maybe before the June 2019 NENA conference in Orlando.  Michael and I are members of that workgroup, and someone will ping this thread or the "911GIS" group when the Python script becomes available. Surprisingly, after ten years of work, the layer names are not explicitly specified by STA-006.1, and some field names are ambiguous, open to interpretation, or inconsistent with naming conventions used in the document.  The issues being resolved by the data model template workgroup are being shared with the GIS data model workgroup, who will include those considerations in "version 2"of STA-006. ... View more

RE: "...our general direction has been moving from the client/server model (directly accessing the geodatabase via a database connection) to a web GIS services model". The architect of this "general direction" is out-of-touch with your user base.  ESRI needs a reality check. Currently, web services only make sense for publishing GIS data on the front end, consuming that published data over the web, and in limited editing scenarios. The plan that feature service editing will replace database replication is not realistic at this time.  A web services architecture might work 10 years from now.  For years, we've discussed similar web services architecture for provisioning distributed NG9-1-1 spatial databases, but no vendor has built even a working prototype yet. Everyone commenting on this thread has business use cases that author data on one or many local area network clients connected to database servers that replicate to other database servers, in distributed multi-user versioned database editing environments. ESRI has clearly jumped-the-gun on this.  Do not experiment on your user base.  Commit to supporting ArcSDE for another 5 years, while you work out the bugs in a next-generation web services model. ... View more