Latest Contributions by PeterHanmore

Yes, I tried publishing directly from arcCatalog (right-click, share as, etc.) but when you publish that way, you don't have an option to include the data or not.  It always includes the data in the .sd file when you do it that way. The locators themselves (the individual locators) are generated from layers in a file geodatabase in a subdirectory of the one where the locator was created (eg. /locator_dir/fgdb_dir).  This should be irrelevant after the locator is created though, since all the data is indexed in the .lox file anyways. For the composite locators, the paths stored in the .loc file appear to be relative local paths to the individual locators (path = .).  I am trying to publish directly from the server, so the paths are all valid.  I did create a /published subfolder to put a copy of the locators in, and mapped this directory to my datastore in ArcGIS Server Manager (the mapping is publisher location d:\locators = server location d:\locators\published).  I also created a datastore mapping for d:\locators as the publisher and server directory. For the composite locators, I now have a copy of the individual locators both in the root directory (D:\locators) as well as the published directory (D:\locators\published), so I'm not sure why it can't map the individual locators. ... View more

Brian Oevermann Thanks for your quick reply. I did a bit more digging through the xml file and think I've found the solution. I noticed that the MultiLineAddress section differed slightly from the NormalAddress - it was missing the OptionalFraction element (<elt ref="OptionalFraction" weight="40"/> ).  I added that in and reloaded my locator and it seems to be working better now.  Not sure why is worked okay with alpha suffixes like 'A' or 'B' but if it works, who am I to argue. Peter. ... View more

Brian Oevermann, This thread is a bit old, but I was testing your locator style (we're using 10.2.2) and noticed that fractions in the house number don't seem to be recognized when using multi-line input.  Multi-line works fine with other suffixes, like A,B or C - just not with fractions.  I tried using 1/2 (i.e. 3 ascii characters) and ½ (ascii &#189; ) - neither works.  Single line input DOES recognize fractions and returns the correct results. Have you tested your style with fractions on multi-line inputs?  ... View more

Has there been any resolution to this problem?  I am running into a similar (exact?) situation while trying to migrate some geoprocessing services based on custom DLL's from 10.05 to 10.2.2.  I'm getting the invalid tool message for everything I publish.  I even took the sample 'Calculate Area' VB code and compiled it as per the instructions (any CPU, registered it with 32bit and 64bit esriregasm.exe, etc.) and it works fine in ArcCatalog 10.2.2 and publishes fine to ArcGIS Server 10.2.2 but when the task is run, the 816 error is always returned.  No other messages of any value are to be found anywhere.  I was able to open the .rtl file (mentioned in previous post) and rerun it successfully. Is there a problem with trying to use custom DLL's on AGS 10.2.x 64bit?  Any thoughts on where to look would be appreciated. ... View more

Peter, Statement #3 is correct.  All aliases will be treated as if they are exactly the same. Brad I meant to edit my post but you answered before I could  🙂 #3 should have read: Same as #1 AND Queens, Brooklyn and Manhatten can all be called New York #4 should be: Same as #2 AND order not at all important - New York or Queens or Brooklyn or Manhatten could have been the primary name.  Every name is equal to every other name and has no bearing on how a city is found in the index. I'll say that #4 does NOT work as it represents our initial understanding of aliases which is disproven by my tests shown in the original post. ... View more

It really doesn't matter the order of the aliases because they are all treated as equivalent but the first alias in the list is treated as the primary. Brad Sorry Brad, but I'm finding your answer a bit contradictory.... If the order doesn't matter because they are all equal, then there really isn't (shouldn't be) a need for a 'Primary' city name. A primary name would only be a necessity if other names had a relationship to it (ie. they are alternates for the first name, but not alternates for other names in the list). So... for clarity, which of these statements is the correct one: 1) when someone adds a new set of aliases to the template, they MUST put the primary name first followed by any aliases in random order?  This will result in any of the 2-n aliases being equivalent to the first name but not other non-primary aliases. Ex. New York, Queens, Brooklyn, Manhatten are in a list of aliases; The primary name is New York but can also be called Queens, Brooklyn or Manhatten, but Queens is not an alias for Brooklyn or Manhatten (and vice versa). 2) when someone adds a new set of aliases to the template, the order has no relevance and all names in the list are all aliases for each other. Ex. same alias list as above.  New York can be called Queens, Brooklyn or Manhatten AND Queens can also be called Brooklyn or Manhatten. 3) same statements as above except Queens could also be called New York (reversing the order - primary name is also an alias for alternate name) OR.... am I missing your intent completely.  Just looking for clarity. Peter. ... View more

it can be the first, second, ... or even last entry in the alias definition. If that's the case (order does not matter in the template) how does it know what order to put them in when you create a locator?  Since, from my testing, the city stored with the spatial record has to come first, how does the locator know which city in an unordered list of aliases has to come first? Or, is it up to the developer to ensure that the first name in a group of aliases is the primary name and then all OTHER aliases can be in any order? Peter. ... View more

It never hurts to dump the REST cache as well (http://servername/Arcgis/rest/admin ). Stopping and starting the service should invalidate the cache anyways, but we've had to manually clear the cache at times in order to see updates. ... View more

What I state is that the results shown using the ArcMap geocoding tool can be incorrect and unpredicatable. My screenshot shows that none of the addresses were matched automatically even though they have scores of 100%.  The minimum score for automatic matching was 75%.  Therefore the results contradict each other - if the minimum match score was achieved the geocoding was successful and this should be reflected in the totals of matched/tied/unmatched addresses but they are not. In addition, if you simply click on the Automatic Rematch button, you will often see the results change - sometimes from 100% unmatched to 100% matched. The geocoding service itself is returning the correct/expected results when the same addresses (that ArcMap failed to show as geocoded) are submitted through the REST interface, so we can be certain that it is not a problem with the ArcGIS Server service.  ArcMap does not use REST - it uses SOAP and the traffic is in compressed binary format so we can't look at the traffic with tools like Fiddler2.  I'm not saying the problem is with the REST service - in fact I doubt that it is - I think the problem lies in the logic of the geocoding GUI within arcMap.  Our .NET and FLEX based applications which consume the REST services all appear to be working correctly - the JSON responses are formatted correctly and have all the information necessary to determine if a match was found or not. I would at least like to be able to pinpoint why this behaviour is occuring.  At least then we can document it for our users, and hopefully provide a solution as well. ... View more

In the .loc.xml file for your locator, look for the <def name="NormalAddress"> section. The default order of the address components in this section is Number, Street Name <elt ref="House" weight="15"/> <elt ref="FullStreetName" weight="80" pre_separator="required" separator_list=".,;-"/> you should be able to switch these two lines around to match the structure of your Faroe Island addresses: <elt ref="FullStreetName" weight="80" pre_separator="required" separator_list=".,;-"/> <elt ref="House" weight="15"/> You might need to remove the pre_separator property since the street name is now the first component in the address ... View more