Latest Contributions by BillRose

Did you ever solve this? ... View more

I can confirm that rolling back to the 3.1 release resolved this same issue for an application with two maps. ... View more

This looks promising, but won't be usable until ESRI provides VS 2013 support for the SDK. http://visualstudiogallery.msdn.microsoft.com/9abe329c-9bba-44a1-be59-0fbf6151054d ... View more

I see many of the same parsing issues with this locator that Roy Jackson describes here: http://forums.arcgis.com/threads/28535-Geocoding-Addresses-with-Apartment-Units?p=208831&viewfull=1#post208831. For example, "999 Little Knoll Lane" is standardized as HN: "999", SN: "Little", ST: "Knl", UN: "Lane". Bill, ...Let me know how it works (if it works) for you. Brian ... View more

That did it. Thanks! Bill, I'm not sure why my attachment is not working correctly.  Post #35 in the link below should be the same file after Brad from ESRI made some tweaks.  There is a lot that the white paper fails to cover... http://forums.arcgis.com/threads/28535-Geocoding-Addresses-with-Apartment-Units?p=128250&viewfull=1#post128250 I "re-zipped" the file and I am attaching it yet again, but I am guessing that it is a problem with the system and not the file specifically. Brian ... View more

Sorry but this link has the same problem as your older post (#10)... The attachment can't be downloaded. Whoops! In my haste I grabbed the old style.  Attached should be the latest.  Apologies to all... Brian ... View more

Is this for 9.3? The file I found here is not xml. Roy, I just noticed your post, so I am attaching the file again. Brian ... View more

Just want to add support for this post.... I recently used the standardize addresses tool and observed the same issues Roy describes. I also see that ESRI has not included a "building unit" locator style in the new features for 10.1. This really is needed. Hi Brad, I have been doing a ton of testing, using addresses across the nation with your updated locator, and have a couple issues to report.  Using your locator with the standardize addresses tool, all street names with two words, and no street type or suffix directional or unit type / num, are parsed incorrectly.  The second word in the street name gets placed into the ADDR_UN field.  For example, try to run standardize addresses with "100 RACING WINDS".   WINDS gets parsed to UN.   There are lots of streets and addresses under this scenario.  This in turn is messing up results for geocoding / get address candidates.  So, if you have 100 RACING WINDS in your data, you use your locator, and run geocode to find the same address, it doesnt match.  However, 100 RACING # WINDS will match.  When you pass in an address without a unit designator to the get candidates method, addresses having a unit are ranked the same as an exact match without a unit.  This effectively means that the geocoding operation does not perform correctly for any location having secondary addresses (has units) AND a primary address (no units), such as an apartment building with a office at the primary address.  As a result of these issues, my code has to look at an address, determine if there is a secondary using our own parser, then based on presence / absence of secondary either use your locator with every address in my data, or the US Address (no units) locator with ONLY the addresses in my data that lack unit type and num - very clunky and not possible for most other users.  Who do you recommend that I contact at esri to work through these issues?   Are you actively updating this locator? I would be happy to provide additional documentation / screenshots of the discrepancy patterns.  Thank you, Roy ... View more

To follow up on my last post, we've solved some problems by moving our unusual building number suffixes into the unit field. But we're still seeing issues with both of the locators posted here. Most puzzling is why a very simple address like '5998 Someplace Ave' sometimes fails to match. These addresses have always matched with the standard out-of-the-box locator styles. Could it be that the absence of a building number suffix and/or unit is lowering their score? ... View more

I've spent some time with the latest versions of the two locators posted here Brad's "USSingleHouseUnits.lot" (post #44) and Brian's "USAddressWithUnit.lot" (post #35). Is it possible to combine these by adding the fractional address field to Brad's locator? Also, we happen to have addresses that use both fractions and values such as "B" and "1001" in the building number suffix field. So all of the following are valid: "1200 1001 W Main St", "1200 1/2 W Main St", and "1200 B W Main St Apt 2." Neither of the posted locators seems to handle all three of the above formats. Can this be accommodated? ... View more

Is there any plan to roll a unit locator style such as those posted here into the core product? We need to build something similar but I am not keen on using something that is not officially supported. ... View more

Here's another suggestion to complement Frank's response: create a spatial view and/or standard SQL view for your sources before doing the join. This will weed out any fields you don't want displayed in the output. And I believe it will provide some control over field order, though probably not over OBJECTID and other special fields. Joins that use layers and table views insist on keeping all fields in the output, even when you've excluded them in your model. ... View more

I don't think there is any.  We have been using a SQL Cluster with sde for a few years though, so I can tell you that for the most part you just set up your cluster and then treat it like a normal SQL server.  Instead of installing an sde service on your SQL server, you use direct connect in ArcGIS.  I don't remember how I did the install for ArcGIS 9 (I think I used the SDE installer to create the geodatabase), but in version ArcGIS 10, the Post Install crashes if your DBMS system is a remote system.  That means you have to set up the geodatabase manually. It is also possible to configure MSCS for ArcSDE services. See http://www.esri.com/systemsint/kbase/docs/arcsde-sqlserver.pdf. This document was drafted for ArcSDE 9.1. It would be nice to have an update to this document from ESRI for 10.0 and Window Server 2008. Most or all of the original document should still be valid, but it could be more polished for the average user... setting up new services can be tricky. I'd also like to see more best practices here if such recommendations exist. For example: would it be a good idea to create a new MSCS group to differentiate ArcSDE resources from MSSQL resources? ... View more

We have the same problem here as originally posted except that we are using Windows XP sp3 and ArcGIS Desktop 10.0 sp1 (build 2800). We are attempting to open a map package downloaded from a public ArcGIS Online map. The ArcMap error message is "Could not open the specified file." ... View more

Thanks for this post Jeff. I haven't seen the "not pooled" requirement for Mobile edits before your post. We are experiencing protocol errors on posting edits (but not getting data). This still happens after adding IUSR to the Mobile root directory and disabling pooling. This is good to know because it is the default setting. Do you know of any documentation on this? Also, can you tell me if your SOC account has any special perms on \Mobile? *Mobile working now* The Awesome Chris O. of ESRI support has helped resolve the last issues I had. These are the changes we made to get MPC and our Juno's working with the web server. IIS Authentication settings: Mobile (root) - Anonymous Auth enabled Admin - Basic Auth enabled (only) Content - Anonymous Auth enabled ContentRoot - Anonymous Auth enabled ItemsRoot - Anonymous Auth enabled __________________________________ Make sure that the Mobile root (via inetpub) has the "IUSR" added to the security tab, and that it has full control. Finally, don't forget that your webservice must be "Not Pooled" if you are doing any kind of edits. Otherwise you will get Protocol errors while managing your edits. -good luck ... View more