|
POST
|
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?]
... View more
04-03-2014
12:50 PM
|
0
|
0
|
3428
|
|
POST
|
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.
... View more
03-26-2014
08:48 AM
|
0
|
0
|
2161
|
|
POST
|
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.
... View more
03-25-2014
02:28 PM
|
0
|
0
|
2161
|
|
POST
|
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.
... View more
03-25-2014
02:22 PM
|
0
|
0
|
2161
|
|
POST
|
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.
... View more
03-24-2014
02:29 PM
|
0
|
14
|
7278
|
|
POST
|
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.
... View more
02-27-2014
12:25 PM
|
0
|
0
|
1090
|
|
POST
|
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.
... View more
01-13-2014
09:41 AM
|
0
|
0
|
1466
|
|
POST
|
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.
... View more
01-08-2014
12:40 PM
|
0
|
0
|
1466
|
|
POST
|
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.
... View more
12-17-2013
05:45 AM
|
0
|
0
|
1674
|
|
IDEA
|
-->
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.
... View more
12-11-2013
01:54 PM
|
7
|
1
|
678
|