Latest Contributions by BrianOevermann

‎04-23-2014

You might also want to check out the tool described in this forum post: http://forums.arcgis.com/threads/93962-Street-Listing-Tool?highlight=create+index It does a similar job as the VBA-based indexing tool I posted way back in the days before VBA was retired and data driven pages were on the scene. I'm glad Adam stepped up and created this version because a job change and lack of time prevented me from updating my original tool. Thanks, Adam!

‎04-23-2014

I asked my support tech that question. He indicated that the bug still exists and has not been fixed up to this point, which would include 10.2.2. The NIM has an entry date of July 29, 2013 but is classified as low severity. This bug didn't immediately jump out at my support tech, but I think he may have been too focused on the Flex viewer angle rather than the fact that it was failing at the REST endpoint level. I am guessing that there haven't been many support calls regarding this that would cause them to elevate this bug's status. For the record, having the percent sign as part of the table doesn't seem to matter in ArcMap other than when you publish your map as a map service, so I suspect many people are happily plugging along without noticing anything amiss. The tech indicated that the dev team would be looking at what they might be able to do with the drag-and-drop functionality to prevent this from happening, but given that it has a low severity status I will not be holding my breath for a fix anytime soon--unless it is something super quick to fix. At least the workaround using the Add Data tool is available. The drag-and-drop functionality is convenient, but using the Add Data tool is not burdensome.

‎04-22-2014

I thought I would give one last update on this issue in case anyone is researching a similar issue. ESRI has logged a bug, at version 10.1 sp1, for this issue. Bug # is NIM093503. FWIW, I didn't have an issue at 10.1. It actually worked fine for me at 10.1 but failed at 10.2. Read the thread entries above for all of the details and the workaround I was able to use to resolve my issue.

‎04-08-2014

...And I rarely use the "Add data" tool now that there is a Catalog tool docked on one side of my ArcMap interface. It's sad that it never occurred to me that ArcMap might treat different ways of adding data, well, differently! I was trying every other possible variation I could think of. What baffles me is that there was a similar issue at Server 10.0 that got "fixed" at 10.1 but "broke" again at 10.2. But you won't see me volunteering to compare millions of lines of Server code to attempt to find the "fix". 🙂

‎04-08-2014

I thought I would give an update on my issue... I opened a support incident with ESRI and after a number of back-and-forth discussions/screen shares plus research on ESRI's end, we believe we found the source of the problem and a workaround. To summarize, when I add my SQL Server-based tables to ArcMap for joining to my feature class(es), ArcMap adds a '%' symbol in front of the table name. [see the message chain above for complete context]. This is NOT an issue with the Flex API (nor Robert's eSearch widget), the issue occurs at the REST endpoint. It turns out that dragging and dropping a table from the catalog window adds the '%' to the table name. If I use the "Add data" tool from the toolbar or the File menu, the '%' does not get added. So, the ESRI support tech is going to do more research to determine if there is a bug or if this behavior is by design, but at least I can change my "data adding habits" for SQL Server tables to use the 'Add data' tool and not drag and drop. I will try to update this thread again once the ESRI support tech gets back to me regarding the "bug or design" determination.

‎04-03-2014

Kim, and Wesley, and Katherine, and ... Joe's remarks are spot on. Kim, your workaround of copying the locator out of your file geodatabase to package it up sounds like a huge time-waster if you plan on doing this more than once. I would suggest taking the time to re-create your locators outside of the geodatabase (or perhaps you can copy the existing locators out permanently). To do so: - Create a folder wherever you want to store the locator(s). It should go without saying that this folder should have permissions set to allow access to whichever users need these locators, including the ArcGIS Server account if you want to register this folder with Server. - In ArcCatalog, navigate to the folder and open it up. - Right-click and select New-->Address Locator (or Composite Locator...) - Construct your locator I have my locators in a folder on my map server , which I can access via a mapped drive for administrative tasks like rebuilding as well as consuming them in ArcMap. This folder is registered with Server, so the individual locators do not need to be copied to ArcGIS Server when publishing them. Only my composite locator is copied to ArcGIS Server (because that is by design). I am operating with a single map server, so your architecture may prevent you from using this methodology. You could put the folder anywhere on your network that allows your ArcGIS Server account to access it. Regarding rebuilding the locators: I haven't used the ArcToolbox tool to do so, but use the right-click context menu option, which basically runs the same underlying process. I have found that successful index rebuilding is hit-or-miss unless any map services containing the data used by the locators have been stopped. No errors are thrown, I simply can't get new addresses to be successfully found without stopping the map services first. The locator indexes never seem to get re-written otherwise. [Maybe Joe has a solution for MY issue?]

‎03-26-2014

Robert, Correct. I am on 10.2. The only item in the "Server/REST issues fixed at 10.2.1" list that might seem to apply is: NIM095513 MapService "query" operations should be linked to "data" capability, not "query" capability of the MapService. But that might be a stretch. Contemplating if I should try to arrange another upgrade (to 10.2.1) this weekend if IT staff are available or first put in a support request. My hunch is that there isn't a solution, unless 10.2.1 fixes it, until a patch, service pack, or new release is put out.

‎03-25-2014

Robert, I am marking your response as the "solution" so you get the points. Even though it did not solve this particular issue, it is sound advice for anyone with a similar issue.

‎03-25-2014

Robert, Good catch on the title field entry not being fully qualified. Unfortunately that did not solve the problem. In my attempt to resolve this issue, I deleted the parcel map service and rebuilt it--not just re-published but created a brand new .mxd to publish. I also started from scratch with the esearch.xml file. One query against the Parcel PIN (the first expression in the code block from my original post) was created and the entirety of the output fields shown. (completely typed with no copy/paste just to ensure that there were no "special keystrokes" inadvertently entered). Result was the same error. Removed all of the fields that are from the joined table and the search query works as expected. When I added one of the fields from the joined table, the result was the error. On a whim--and I kick myself for not doing this earlier--I went into the REST service browser and attempted to perform a query against the property owner field of the jointed table. Result is the same error thrown from within the eSearch widget. So... this is NOT an issue with your eSearch widget but rather a bug or something with the way map services with joined tables are published in 10.2. In a previous version of Server there was some joined table "wackiness", so I guess that has been re-introduced. My workaround before was to export the layer with the joined table to embed the join fields, then use that to publish my map service. That works, but it adds an additional process to all of my maintenance whenever either the parcels or the Assessor data changes (which is at least monthly for the Assessor). What is strange is that I have my site addresses joined with a table from the same database, so the "structure and source database" of the join is the same. THAT one works, though I've now probably just caused it to fail by the mere mention of it! Thanks, Robert, for the fresh look at my config on this.

‎03-24-2014

I recently upgraded our Server from 10.1 to 10.2. I also took the opportunity to roll to the latest version of the Flex Viewer (3.6) from 3.4. Prior to upgrading the Server, I prepped the new viewer and everything was working great. Once I upgraded the Server to 10.2, however, I now get an error when I attempt to do a search against my parcel layer. The error is "[RPC Fault faultString="Unable to complete operation." faultCode="400" faultDetail="An SQL statement with comments and/or semicolon is invalid."]. The parcel layer has joined Assessor data, but nothing changed with the map service (other than upgrading to 10.2) nor did I change anything in the eSearch config for this layer. The relevant code block from the eSearch config is: <layer> <token/> <definitionexpression></definitionexpression> <enableexport>true</enableexport> <name>Parcels</name> <url>http://server-name:6080/arcgis/rest/services/General_Mapservices/parcels/MapServer/2</url> <expressions> <expression alias="Parcel ID" textsearchlabel="Search by Parcel ID:"> <values> <value prompt="Example: 2724069035">coivector.COI.Parcels.ParcelPIN = upper('[value]')</value> </values> </expression> <expression alias="Owner Name" textsearchlabel="Search by owner name:"> <values> <value prompt="">Assessor_Info.GISMAP.%ParcelInfo.PropertyOwner LIKE upper('%[value]%')</value> </values> </expression> <expression alias="Plat Name" textsearchlabel="Search by Plat Name:"> <values> <value prompt="Example: ENGLEWOOD ADD">coivector.COI.Parcels.PlatName LIKE upper('%[value]%')</value> </values> </expression> <expression alias="Site Name" textsearchlabel="Search by site name:"> <values> <value prompt="Example: GILMAN VILLAGE">Assessor_Info.GISMAP.%ParcelInfo.PropertyName LIKE upper('%[value]%')</value> </values> </expression> <expression alias="Appraised Land Value" textsearchlabel="Search using appraised land value:"> <values> <value prompt="include operator i.e. > 500000">Assessor_Info.GISMAP.%ParcelInfo.AppLandVal [value]</value> </values> </expression> <expression alias="Appraised Improvements Value" textsearchlabel="Search using appraised improvements value:"> <values> <value prompt="include operator i.e. > 1000000">Assessor_Info.GISMAP.%ParcelInfo.AppImprVal [value]</value> </values> </expression> <expression alias="Total Appraised Value" textsearchlabel="Search using total appraised value:"> <values> <value prompt="include operator i.e. > 2000000">Assessor_Info.GISMAP.%ParcelInfo.TotalAppVal [value]</value> </values> </expression> <expression alias="Appraised Land Value-sq. ft." textsearchlabel="Search using appraised land value per sq. ft.:"> <values> <value prompt="include operator i.e. > 90">Assessor_Info.GISMAP.%ParcelInfo.AppLandValSF [value]</value> </values> </expression> <expression alias="Appraised Improvements Value-sq. ft." textsearchlabel="Search using appraised improvements value per sq. ft.:"> <values> <value prompt="include operator i.e. > 200">Assessor_Info.GISMAP.%ParcelInfo.AppImprValSF [value]</value> </values> </expression> <expression alias="Total Appraised Value-sq. ft." textsearchlabel="Search using total appraised value per sq. ft.:"> <values> <value prompt="include operator i.e. > 200">Assessor_Info.GISMAP.%ParcelInfo.TotalAppValSF [value]</value> </values> </expression> <expression alias="Commercial Building Gross Total Sq. Ft." textsearchlabel="Search using commercial building total gross sq. ft.:"> <values> <value prompt="include operator i.e. > 500000">Assessor_Info.GISMAP.%CommBldg_GrossSF_by_PIN.CommBldgTotalGrossSF [value]</value> </values> </expression> </expressions> <graphicalsearchlabel>Use one of the graphical search tools to select parcels</graphicalsearchlabel> <spatialsearchlayer>true</spatialsearchlayer> <titlefield>ParcelPIN</titlefield> <fields all="false"> <field name="coivector.COI.Parcels.ParcelPIN" alias="Parcel PIN" gridfield="true"/> <field name="coivector.COI.Parcels.PlatName" alias="Plat Name" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.PropertyName" alias="Property Name" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.PropertyOwner" alias="Property Owner" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.OwnerAttention" alias="Owner Attention" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.OwnerAddress" alias="Owner Address" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.OwnerCityState" alias="Owner City-State" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.OwnerZipCode" alias="Owner ZipCode" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.Plat" alias="Plat" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.Lot" alias="Lot" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.Block" alias="Block" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.YearBuilt" alias="Year Built" gridfield="true" gridfieldonly="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.LotSF" alias="Lot Sq Ft" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.AppLandVal" alias="Appraised Land Value" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.AppImprVal" alias="Appraised Improvements Value" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.TotalAppVal" alias="Total Appraised Value" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.TotalAppValSF" alias="Total Appraised Value Sq Ft" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.AppLandValSF" alias="Appraised Land Value Sq Ft" gridfield="true"/> <field name="Assessor_Info.GISMAP.%ParcelInfo.AppImprValSF" alias="Appraised Improvements Value Sq Ft" gridfield="true"/> <field name="Assessor_Info.GISMAP.%CommBldg_GrossSF_by_PIN.CommBldgTotalGrossSF" alias="Commercial Building Total Gross Sq Ft" gridfield="true"/> </fields> <icon isfield="false"></icon> <links/> <zoomscale usegeometry="true" zoompercent="2"></zoomscale> <autoopendatagrid>false</autoopendatagrid> </layer> These queries have worked through multiple versions of the eSearch widget (with appropriate config file tag adjustments), so I am at a loss as to why there is suddenly an issue. Could the error be referring to something in the result set rather than the SQL query syntax itself? FWIW, the same map service is successfully used in the Identify widget. A similar table of joined info is used with my site address layer and successfully performs search queries as expected. It uses the same database connection as the joined info in the parcel service. I'm not sure if this is an eSearch issue or something with Server 10.2. Nothing in the "What's new in 10.2" seemed to indicate that esri did anything major with with SQL queries and map services, but that doesn't mean a minor change somewhere has created this issue. Any thoughts? Thanks.

‎02-27-2014

Something is definitely amiss. I am currently using v3.4 on Server 10.1 with my own Export Web Map Task and have it set to 300 dpi. Letter sized pdfs process in a few seconds. An Arch E size plot set to print at 1200 scale takes about a minute to a minute and a half, but that is a lot of data to process for such a large paper size. I'm currently rolling my viewers up to v3.6 and my Letter sized pdfs are taking around a minute. The Arch E size plots are well beyond 5 minutes. I'm not sure how long exactly because that's the limit of my patience for testing and certainly not acceptable for my users. So something changed between API 3.4 and 3.6 because I haven't done anything to the Export Web Map Task or any of my cached or dynamic basemap services.

‎01-13-2014

Anjolette, I am afraid I will not be of much help, as we currently do not use alternate name tables nor are we on 10.2 yet. But I would be interested in the solution because I have been contemplating adding alternate names into our locators. Hopefully Brad from esri or someone else has an answer or suggestion(s) for you.

‎01-08-2014

Roberto, Are you asking if a style using units or apartments is available out-of-the-box at 10.1? The answer is no. But the style I contributed in this thread, as well as Brad's, are usable in 10.1. There is a GIS Idea requesting such a style be part of the core list of styles that you can vote your support for. The link has been put in this (response #8) and other companion threads on this same subject.

‎12-17-2013

Steve, It is unclear which locator style you are referring to when you say "this one". The included quote seems to imply my version but to be clear since there are two different unit-based locator styles circulating on this thread: - Brad (esri) created a style that includes units, and... - I created a style that includes units and also has a separate field for fractional portions of an address (my style was tweaked by Brad due to lack of info in the white paper) Depending on the thread response (and link within), it can get a bit confusing which is which. The telling indicator is the inclusion of the fractional field in the style properties. Brad's will do fractionals but only if the fraction is part of the house number field. Our data is set up with the pieces separated, making the different style necessary. While I cannot definitively say (since I don't use that version) that Brad's locator style will work with mixed alpha and numeric units, it should have no problem doing so. I CAN definitively say that my version does work with mixed alpha and numeric because our data contains such units (i.e. A-3, B101, 2-C, etc.) and matches them with no issues.

‎12-11-2013

When using the Calculate Geometry dialog in ArcMap to calculate x or y coordinates for points, the only options available are to either use the coordinate system of the data source or the coordinate system of the data frame. Many local governments use their relevant State Plane Coordinate System for their data. However, when sharing data we often are requested to have the coordinates expressed in longitude/latitude. In order to accomplish this, we must re-project the data and then calculate the x, y coordinates for the re-projected data. I would like to see an additional option added to the dialog--"Project into:" and allow the user to browse for the coordinate system of their choice. Given that the x, y fields that are being calculated are not updated automatically, I should be able to decide what coordinate system should be used regardless of the data source or data frame.

Online Status	Online
Date Last Visited	6 hours ago

My Ideas

Latest Contributions by BrianOevermann

Re: Fire department map book question - Street index

Re: eSearch 3.6.4 + Server 10.2 oddity

Re: eSearch 3.6.4 + Server 10.2 oddity

Re: eSearch 3.6.4 + Server 10.2 oddity

Re: eSearch 3.6.4 + Server 10.2 oddity

Re: Rebuilding address locators

Re: eSearch 3.6.4 + Server 10.2 oddity

Re: eSearch 3.6.4 + Server 10.2 oddity

Re: eSearch 3.6.4 + Server 10.2 oddity

eSearch 3.6.4 + Server 10.2 oddity

Re: print widget very slow

Re: Locator Style for Apt or Units

Re: Locator Style for Apt or Units

Re: Locator Style for Apt or Units

Calculate geometry dialog - add ability to calculate x, y using any coordinate system

Re: How to convince I.T. to buy computers that can...

Re: How to Change # of Decimal Places in Chart Sta...

Can a field participate in multiple groups in a Fi...

Re: How do I get the map to display full extent in...

Re: How to Change # of Decimal Places in Chart Sta...