Latest Contributions by DavidBollinger

‎10-30-2023

FWIW (very late reply)... The direct url format given above is correct, but it's for a mapservice, from a server; not for a webmap, from a portal. To retrieve portal data via a direct url, you'll first need to know its itemid (snoop around a bit). AND, it needs to be shared publicly (or you'll have to separately deal with the oauth stuff). Start by testing this base (this is mainly to verify you didn't change the default name/port/etc): (https://)yourserver.yourdomain.yourtld:7443/arcgis/sharing/rest (adjust as needed for your specific install until successfully reach portal's rest root) Then, for the portal item's metadata, append: /content/items/abcdef0123456789/itemdata?f=json (where "abcdef0123456789" is the itemid of the portal item desired) Or for the actual webmap data itself, instead append: /content/items/abcdef0123456789/data?f=json

‎03-08-2023

I wanted to ping/refresh this topic, and provide some additional information (per my experience anyway), because this is STILL happening (as of 3.1.0), and is INCREDIBLY frustrating! Perhaps the key bit of info is that (for me, at least) this does not occur with file-based data - only occurs with data sourced from our EGDB (MSSQL-based). But for any data stored in the EGDB, the first edit to a field will result in the "cursor moved back before first character typed" behavior - so that typing "123" results in "231", or typing "abc" results in "bca". Sometimes, subsequent edits to that same field (e.g. tab or click away, then come back) will not exhibit the behavior (ie, will work as expected, correctly), but repeat a second/third/etc time and bad behavior might return again. (and this unpredicatability makes it even harder to try to find a "muscle memory" keystroke approach work-around) The field doesn't have to be null (though a null value ALSO exhibits problem) - attempting a first edit to an already-populated field as an "overwrite" will still do the cursor shuffle and "scramble" typing order as described. by OP.. Say a field contains pre-existing value "test", now single-click the field within attribute table, the entire field will highlight, but it's not yet in edit mode (indicated by bold outline and highlighted value inside), now type "abc" intending to overwrite/replace the entire value, and you'll get "bca". I suspect there's something about the timing of the first typed character "auto-entering" edit mode (and perhaps a database read for a row lock) that causes the cursor to reset. The only known workarounds involve using a different activation sequence.. If you slowly single-click twice (not double-click*) the field to highlight it first, then explictly enter edit mode, then any pre-existing value should remain selected and you can overtype it without cursor-shuffle - this is the only "reasonable" work-around known. (*double-clicking isn't as suitable because ~50/50 chance it won't leave pre-existing value selected) 6 bad, 3 good, in this screen capture:

‎09-27-2022

I'm in need of a theme that's essentially a hybrid between the Foldable and Tab themes. Specifically, the controller style of Foldable (in the header), but the outside-of-map side-panel of Tab. I'd rather not start from scratch, so seems like I could kick-start by either: 1) start with Foldable, munge it into using an out-of-map side-panel 2) start with Tab, yank controller out of side-panel into header Foldable seems more stable, so I'm tempted to start there. I don't need any of the "indicator" bars of Tab, nor its ability to arrange vertically, just its out-of-map panel with map-resize-on-open/close logic. I also prefer the right-side panel of Foldable, and Tab doesn't seem to easily support right-sided (I've tried, but the rtl support is only so-so). But thought I'd ask in advance for recommendations/pitfalls if anyone's done something similar before. Thanks. Edit: hmm, pondering my own pre-conceived notions, the Plateau theme is perhaps a better kick-start.

‎11-05-2020

More FYI, in case it helps anyone else: Esri Case #02650635 After some exploration and experimentation, the problem seems to be related to an upgrade of our EGDB to 10.8.1. It was found that all of the unpublishable "bad names" had a similar history: Prior to the upgrade, another featureclass existed in another schema having the same name. For example, if the good copy was: database.Authoritative.Zoning, then there was also something like: database.Temporary.Zoning. So both same-named featureclasses were present during the upgrade, and subsequently appears to have led to some sort of internal "mix up" that caused trouble when resolving names. The "fix" is to simply remove the non-authoritative copy, this will resolve the "bad name" conflict, and the authoritative version will again become publishable. (recreating a same-named featureclass in other schemas after the upgrade does not replicate the problem going forward - in only appears to occur if the same-name-different-schema situation existed during upgrade)

‎10-22-2020

As of ArcGIS Pro 2.6.2, when using Overwrite Web Layer the time zone and daylight savings time configuration options always default to blank, even if the layer being overwritten currently has a defined time zone and DST enabled. Thus the default options will WIPE any previously established time zone and DST enable. Thus you must manually reconfigure those values appropriately on every overwrite. It would be preferable if the tool could pull these values (when present) from the existing service and auto-populate the correct default configuration values, so that the default operation maintains the overwritten layer in exactly the same state as it began. In my opinion, the default behavior of ANY type of "replace"/"overwrite" tool should be to retain everything except that which is explicitly requested to be altered.

‎10-07-2020

FYI, in case it helps anyone else: was replicated by tech support, is being forwarded to developer group (don't know a bug# yet).

‎09-30-2020

I have an otherwise working AGE environment, but I encounter this error when publishing some featureclasses through an otherwise-working registered data store, where it seems to be dependent solely upon the specific name given to the featureclass in the EGDB. That is, certain names seem to be "publishable" while others are "unpublishable", and there doesn't appear to be any obvious reason for it. (e.g., they're not SQL reserved words or such) So, if I take an otherwise unpublishable layer with a "bad name" and simply rename it to a "good name", with no other changes, it then becomes publishable - and vice versa, and repeatable. For example, I know from experimentation that a layer named "Parcels" will be publishable, while a layer named "Zoning" will not be publishable. Rename both of them to vice-versa and the problem follows the name. (many other known good/bad names, but again - no obvious pattern to them) The server log has two relevant entries, the generic part: ERROR 001487: Failed to update the published service with the server-side data location and the detailed part with the connection info that failed to swizzle: Failed to create the service.: Updating the server connection string for layer DummyAsZoning failed. Attempted connection string was <omitted> Table name is <instance>.<schema>.Zoning. Please verify the data exists on the server. I omitted the connection details for privacy but they're known to be valid, AND the connection details are exactly the same as when it's renamed as Parcels (or other "good name") but publishes successfully. Any ideas what might be causing this? Thanks! Environment: AGE 10.8.1, AGPro 2.6.1, MSSQL 2019 (EGDB is 10.8.1)

‎08-28-2020

Another upgrade-duration report FYI: ~4hrs. (i.e., "several minutes" indeed) Agonizing details: About a month ago (~1 week before 10.8.1 release) had completed a brand-new/from-scratch AGE 10.7.1 on a reasonably respectable 4-core 16G RAM 2T HD WinSvr 2019 VM. Fully operational, but still non-production and essentially "fresh"/"clean" - only has a couple "starter" users created, no content yet. Decided to upgrade it to 10.8.1 prior to production. The Portal install sat with an empty "Status:" and zero progress bar for well over an hour, but Task Manager at least showed some minimal activity (which I'm guessing is a backup phase), so I just baby-sat it and waited. The first indication of "it's actually alive" didn't occur til after that (maybe 1.5hr in) when it finally started "doing things" and the progress bar jumped to >50% (ish) where it again sat for a while. Roughly 30min later the progress bar jumps to >90% (ish) and you reach the "Status: Removing files" phase - the progress bar is reset during this, and took another ~30min, but at least you can see "File:"names changing. After that phase, it again resets back to "Status:" blank and zero progress bar, Task Manager shows 0 cpu usage and a static memory footprint for the installer process, so I begin thinking "uh-oh", but I continue to wait. About 30min later get "Status: Copying new files" and progress bar gradually fills (~5min ish)) then stalls at 100% and sits for a bit (~10min ish). Then "Status: Component registration" (~5min ish) then "Status: Copying new files" again - progress bar slowly increments maybe 3%/min, about ~30min ish total, many "File:"name updates during. Then at ~95% progress bar you reach "Status: Installing new services" (~5min ish), then "Status: Configuring the service" (0% cpu during, ~5min ish), then again a brief empty "Status:" and zero progress bar (~5min ish), then, finally, thankfully... "Portal for ArcGIS 10.8.1 has been successfully installed".

‎01-17-2020

I guess I should have instead pushed "Don't Send".. (j/k, lol, , etc)

‎01-16-2020

I'm in the process of migrating a pre-10.5 "just ArcGIS Server" -type architecture to a "full-stack" of AGE. I could use some input from any "network architecture" gurus reading this (including just plain GIS folk who happen to have such knowledge from their own implementations), as I'll eventually need to communicate some sort of plan to our network crew. Essentially, is there a "standard" way to "communicate" AGE's best-practice/recommended DMZ requirements? Granted that different orgs might have want/need to go above/beyond depending on own security requirements, but I'm just considering the "typical" install practices. I'm sort of trying to learn what "lingo" I might need to best specify things for our networking staff. Or,.. Is the drawing below representative of the typical/proper/expected way of setting things up for both internal/external access to the portal?... functionally complete?.. anything missing?... do something else entirely? Thanks! (some things simplified: http:80 traffic not shown (nor AGE's 6080/7080), "external.org" might really be "subdomain.internal.org", "internal.org" may represent >1 server, etc - but hopefully doesn't matter, it's still conceptually "equivalent enough" to our plan to be relevant, mainly the DMZ/firewall portion is the intended focus of the question)

‎08-27-2019

I had this problem too, and believe I have a solution. But first, I assume you've already checked that the help docs don't apply: Step 4: Load a topology to a parcel fabric—Help | ArcGIS Desktop That is, you don't have any true undershoots do you? You have valid polygons and lines, correct? If so, then this FAQ may offer the needed clue (wrt same start/end vertex): FAQ: What are possible reasons for line sequencing errors when converting a topology to parcel fabric? So check those isolated polygons - are they covered by a SINGLE closed-loop line? (OP said theirs was) If so, then THAT is what the cryptic "line sequencing" error message is actually complaining about. To test, simply split that line at any non-end vertex so that the boundary is now composed of two line segments, then try loading again.

‎08-21-2019

Background: ArcMap 10.6.1, latest LGIM. I have a portion of California's CadNSDI PLSS in a local file geodatabase (current ver), and loaded into a parcel fabric. Everything throughout uses the exact same coordinate systems (XY=EPSG2227, Z=EPSG5703) specifically including the ParcelEditing fds and the editing map's data frame. Domain/resolution/tolerance are all the high-resolution defaults (~=0.00032808333333... US Survey Feet) Whenever I attempt an adjustment in the fabric, at the point where it says "Writing adjustment vectors" the following error occurs: "The spatial index grid size is invalid [ParcelFabric_Adjustments]" I'm aware of this: Common errors that may occur during editing—Help | ArcGIS Desktop but it's not (apparently?) possible to drop/recreate/reconfig the spatial index on this "hidden" feature class "ParcelFabric_Adjustments" internal to the fabric. I have attempted to recreate indexes on the points/lines/polys, but it makes no difference. Also tried recalculating the XY extent of each point/line/poly, again no effect. Tried recalc extent THEN recreate index, again no effect. Then I created a personal geodatabase and bulk copied the entire contents of the fgdb into the pgdb. Guess what? That same adjustment succeeded! So what's up fgdb? Problem is, a pgdb really isn't workable for this project. Plan was: eventually, after the initial local adjustment edits were performed, it'd reside in MSSQL. I don't want it in MSSQL prior to that work for performance reasons (maybe it's just our setup, but large-scale fabric adjustments suck in MSSQL, so we were hoping to get the "reference" layers (the PLSS) in good shape via local gdb before shoving them in with several hundred thousand tax and ownership parcels) So, finally a question: Any way I can get the fabric to work from a file geodatabase?

‎08-20-2019

I'm trying to understand the fabric's model as to "where" to put things (re PLSS boundaries). In short, I'm trying to figure out why there are 5 parcel types (1,2,3,4,12) for the cadastral reference portion, when I can only find four in use (township, first div, second div, special survey). Though I do know in some jurisdictions there are third divisions recognized below the quarter-quarter, and I initially thought that was the distinction, and reason for the 5 types, though perhaps suggesting some "mix-up" in naming (ie, "Sections"=2 were to be first divs, "Quarter Sections" type=3 were to be second divs, and (if mis-named) "Second Divisions" would actually be the third divs). But that doesn't seem to be the case, rather it just looks like type=3 isn't used. Conceptually I do prefer the name "Second Divisions" of type=12 (because not every 2nd div is a quarter section) and present-day tools (such as publishing scripts) seem to use type=12 instead of type=3. Just wondering about the "history" of type=3, and does it have any present-day purpose at all?

‎08-19-2019

The default tools that ship with the Land Survey Editing don't deal with the conflicted areas polygons, so I'm wondering if and how to represent them in the fabric. We'll be doing county-wide adjustments against local control, so I'd want them to be adjusted along with the rest of the survey data. Truthfully, they don't get used much, and are really just "metadata" functionally, but for consistency it would seem I'd want them in the fabric just so that they can be properly published back out in post-adjusted form (so as to still match everything else post-adjustment). If kept inside the fabric.. my initial thought was to add another type to the lrSpecialSurveyType domain, similar to how meandered water is handled, and just load them there. Then modify the publishing script so that 1) conflicted areas, 2) meandered water, and 3) everything else are all properly sorted out during publishing from the type=4 special surveys in the fabric. Anything wrong with that approach? The lack of a pre-existing domain value (and absence from the publishing script) makes me wonder if conflicted areas were either 1) not yet accounted for in the model, or 2) considered, but not expected to be inside the fabric. If kept outside the fabric, and just "brought along" with adjustments... my concern would be that I don't know the CadNSDI data model well enough to know if conflicted area boundaries are allowed to be "unique" (ie, not represented by any other feature) in which case you'd definitely need them in the fabric to get a full/proper export of all PLSSPoints and PLSSIntersectedAreas. Perhaps a simpler way to word that secondary question might be: could conflicted areas be ignored ENTIRELY without affecting the validity of publishing? Thanks.

‎08-15-2019

Late to the conversation. I'm investigating AA for automating "left/right" attribution similar to Jay Johnson's question above, any progress on this? (or is there some other existing approach that I've just missed?) What I would envision is a "sided" version of the NEAREST_FEATURE value method, that would also allow the specification of a "percent along" and "distance offset" for linear features. That offset point would then be used to perform the near analysis. Depending on your road data, you may have (as we do) all sorts of left/right two-sided values (various emergency response providers, municipalities, zip codes, reporting districts, etc). So taking just a simple one, say municipality, as an example, you'd have two separate rules for each sided field, here's a fictional mockup: TABLENAME FIELDNAME VALUEMETHOD VALUEINFO RoadCenterlines MUNIRIGHT NEAREST_FEATURE_SIDED MunicipalBoundaries|Name|50|20 RoadCenterlines MUNILEFT NEAREST_FEATURE_SIDED MunicipalBoundaries|Name|50|-20 where the "50|20" part would mean "50 percent along, and 20 maps units perpendicular" (along with a convention for determining which sign value of the offset means left or right - I think negative=left makes most sense when oriented with from-to vertices)

Online Status	Offline
Date Last Visited	‎01-16-2024 10:20 AM

My Ideas

Latest Contributions by DavidBollinger

Re: Add REST endpoint service to web map without web adaptor

Re: Why does the cursor change position after inputing a single character in a NULL field?

Custom Theme - easier to start w Foldable or Tab?

Re: Error 001487 when publishing SOME featureclasses

Pro: Overwrite Web Layer, use prior time zone & dst as default config

Re: Error 001487 when publishing SOME featureclasses

Error 001487 when publishing SOME featureclasses

Re: Upgrading to ArcGIS Enterprise 10.7 and Portal installation has no progress

ArcMap 10.7.1 meta-error

typical/standard/proper/expected DMZ architecture?

Re: Isolated Polygons Result in Line Sequencing Error in Topology to Parcel Fabric

Parcel Fabric LGIM - "The spatial index grid size is invalid" during adjust

Were fabric type=3 "Quarter Sections" deprecated for type=12 "Second Divisions"?

Handling CadNSDI's PLSSConflictedAreas in a fabric

Re: If you’re using the Attribute Assistant, we need your help!

Re: Add REST endpoint service to web map without w...

Re: Error 001487 when publishing SOME featureclass...

Re: Upgrading to ArcGIS Enterprise 10.7 and Portal...

Re: Creating wedge-shaped territories

Re: Creating wedge-shaped territories

Web AppBuilder Custom Widgets