|
POST
|
Emily, Your unit (and dir) fields are still not truly null--you have just eliminated the spaces. If they are truly null they will look like the attached screenshot. There are multiple ways you can accomplish this, but if there is only a space (or a "blank") I have found that I need to add some actual characters (i.e. asdf), commit them, then select that new value and hit delete on the keyboard. This is via the attributes window when editing. Hopefully I have described it well enough for you to get the idea. That said, when I did actually null your unit field, I was still unable to get the locator to properly find a match. I didn't exhaust all of the possible reasons/causes because I simply don't have time to do that level of troubleshooting for you. I still think it has something to do with how your data is formatted but I am unsure exactly what that might be. Your data does not have all of the same fields as mine, but when you set up the locator and specify the fields to be used it should be using only those fields for matching (from what I understand about the process). You are the first person that seems to have this issue with the locator, or at least the first person to raise the question. Maybe others have simply abandoned it without saying anything. Regardless, I can tell you that my locator finds single family addresses as well as those with units. My users wouldn't be happy with me otherwise! You can see it actually working via our current 'placeholder' (until I can build more focused viewers) public viewer on our website at: http://products.issaquahwa.gov/GISviewer/index.html Sample addresses are: 130 e sunset way = our main City Hall, but equivalent to a single-family address without a unit 360 nw dogwood st unit r201 = address with unit. For matching purposes you can even leave off the 'unit' and only type the 'r201' Full disclosure: the viewer is actually running a composite locator made up of: single house with unit, US Address (streets), and single-field input, in that order. If you type in a proper address it should locate it to the site address point using the single house with unit locator. Also note that capitalization is not necessary. You might try digging up Brad's (from esri) version of a unit-based locator and see if you have better luck. You mentioned in a previous post that the "regular" SingleHouse locator worked. That is to be expected because the way that locator is built ignores information regarding units--it knows nothing about them. So I would expect that the locator would work well with addresses without units as well as those with units. But for those with units, the locator is only matching the base address.
... View more
07-03-2014
08:13 AM
|
1
|
1
|
1412
|
|
POST
|
Emily, I will answer your latest question and then comment on the testing I have done with your data... Re: batch geocoding with a table that contains the unit in a separate column from the address - To my knowledge the entire address to be matched must be in a single column. I don't batch geocode often, but I seem to recall only being able to specify one field/column that contains the address to be matched. Someone please correct me if I am misinformed! Re: testing [apologies for the length] So... I added your data to a new ArcMap project, then added your locator built with the style file I uploaded to the forum to ArcMap via the Geocoding toolbar. I used your AddressTable table to inform me of sample addresses and typed an address containing a unit as well as an address without a unit and got the same results you indicated--those addresses without units were not found. I closed ArcMap and then created a brand new locator against your address point data. My thought was maybe the upload got corrupted somehow and using the locator style that is on my system (that I successfully create locators with) could confirm that possibility. After loading the new locator into ArcMap in the same way described above, my results were still the same. I next took a closer look at your data. Within the unit field, if an address does not have a unit associated with it, the field is populated with a 'space'. In the unique values list within the 'select by attributes' dialog it looks like: ' ' . A space as a value is not the same as a NULL value, and I suspect that might be the reason for the failed address match. In an attempt to confirm that, I edited your data to null the unit field. The most that would do is change the value in the unique values list to: '' . That also is not the same as NULL. Typically the result of nulling the field is an entry of NULL, so I started looking at your feature class schema. For your UNIT field (and for your DIR field as well) you have the field set to NOT allow NULL values, which is why I was not able to completely NULL the field. You likely have a sound business reason for disallowing NULL values on these fields, but general best practices are that you only disallow NULLs when you absolutely require something to be filled in that field. For street directionals and units, you may or may not have a value. That is why I found spaces as values--a user must put something in the field. And while a space is not equal to NULL, it IS a valid value that satisfies the field not being NULL (and the field otherwise looks blank). All of that said, I think that if you recreate your feature class and set the DIR and UNIT fields to allow NULLs, you will find success with the address matching. If your business rules require those fields to not have NULLs then you are likely stuck. You may want to test it so that you can make a sound business case to change the rules accordingly. You should be able to import your fields from the existing layer and make the required changes before completing the creation of the new feature class, then use the simple data loader to load all of your features from the old to the new. You will need to then NULL those two fields where a value does not exist. At that point, re-create your locator--you could try rebuilding the existing one but why take the chance--and attempt your address match again. I hope this all makes sense...
... View more
07-02-2014
10:30 AM
|
0
|
0
|
1412
|
|
POST
|
Emily, That is strange, as I have no issues locating addresses that do not have a unit/suite associated. I'll compare your data schema with mine--maybe there's a slight difference? I'll work in a test for you but likely won't have a chance until tomorrow.
... View more
07-01-2014
02:12 PM
|
0
|
0
|
1412
|
|
POST
|
Patrick, My version of the style hasn't changed, so the file available on other threads is still valid. Regardless, it is attached for your convenience. At this writing my organization is using 10.2.
... View more
06-30-2014
06:43 AM
|
1
|
3
|
1459
|
|
POST
|
I've had hit and miss luck with legends in my print templates. It seems to work better if you have a core set of layers that you are making available to your users. That said... You might try creating a legend "window" in your layout that spans the entire white space that you appear to have available for your legend. You also should set, in the legend properties, more than just a single column for the legend. The legend properties, by default, is a single column. You will want to experiment with the number of columns. I found that it worked better when I put in way more columns than I thought were feasible for the space I allocated to the legend (i.e. I thought no more than 5 or 6 columns would fit but I set it to 10 columns (just an example)). Designating the number of columns seemed to work better when I was initially setting up the legend, and less so when I attempted to tweak the legend options later. The other big tip--and you didn't mention this so you may already have this covered--is to leverage all of the legend options available to maximize the ability of the system to generate a readable legend that fits on the map. You should go into the Items tab in the properties and check the box for each available layer to only show the features that are in the current extent. This will eliminate any legend patches of features that don't exist in the current view. This is a big help with, for example, a zoning map that is zoomed in to only show a small area where only a few different zones are present. You don't need the legend to show every zone within the City/County in that context. You should also play around with the word wrapping functionality. You can set a maximum length for a legend entry and have it wrap to a new line. For example, if you have a feature that is titled "Sites within project area greater than 5 acres" the word wrapping function will split that title into 2 or more lines. Along with your column setup, this can maximize the layout of the legend. There are a few other options in the legend properties that you can tweak to get the most out of your legend. These tips really are useful for all of your maps. If you have set up your templates in a folder that is registered on the server instead of having your layouts copied to the server, maintenance of your templates is really easy (as well as adding additional templates later). I suggest creating a test layout template, and within the flex viewer add a bunch of layers to your map (many more than logical) and see what the print result is. From there expand columns, etc. until it starts looking like you want it. With the dynamic nature of the templates you really need to play a bit to see where it might break, unless you really constrain your users with the data available.
... View more
06-27-2014
02:38 PM
|
1
|
2
|
2068
|
|
POST
|
Emily, I can confirm that the style I've uploaded--that contains a field for the fractional portion of the address--works at 10.2. I would expect that the style that Brad from esri has uploaded also works, but I cannot confirm that since I don't use that style. Were you having trouble getting either to work? You should be able to find the links/files in earlier thread messages and even in one or two other threads if you haven't already downloaded either of them.
... View more
06-27-2014
06:24 AM
|
0
|
0
|
1459
|
|
POST
|
Jonah, If I recall correctly, the help outlines a couple of different methods related to using your own templates. One is via publishing an Export Web Map gp print task. The other is discussed under the umbrella of "advanced printing". Are you talking about the Export Web Map gp task when you say "...published...a geoprocessing service"? If so, you either save your mxd templates in a folder or let ArcGIS Server copy them onto the server (recommend the former) per the instructions in help. The config file entries for the Flex viewer are really minimal, regardless if you use the Application Builder or the source code. I suspect you were following the help related to the "advanced printing", as the result is something that you then need to program your own front end to use effectively. Just my opinion. I effectively serve up letter-sized to E-sized templates to my users with the Export Web Map print task, with excellent results just by following the instructions in help carefully.
... View more
06-05-2014
02:42 PM
|
0
|
0
|
417
|
|
POST
|
Alejandra, I think I may be at the end of any suggestions I am able to make regarding this. I have no experience with WMS services, so I don't know if there are any tricks with getting those to work with editing and the Flex viewer. Typically, backward compatibility of datasets can be an issue. But I don't know if an ArcGIS 10-based WMS service is incompatible with ArcGIS 9.3 even though your user is consuming the data as a service and not directly. Your comment that you can sometimes see the service but not consistently sounds like a connectivity issue of some sort with the server. Unless someone else here in the forums has something to offer, your best bet may be to start a support incident with ESRI. I'm sorry I cannot offer anything more...
... View more
05-23-2014
11:03 AM
|
0
|
0
|
560
|
|
POST
|
Alejandra, You mention a WMS service. Are you referring to the fact that when publishing your service you checked the "WMS" box in the Capabilities list or are you using 'WMS' as a generic term for the service? If you are publishing and sharing the service as WMS I will be of no further help, as I have never needed to publish my services in that way. Hopefully someone else on the forums can respond or perhaps this warrants a support call to ESRI. If you are using WMS generically, in the Capabilities list for services that have editing capabilities I check the "Feature Access" capability. This enables the geometry to be served up via the FeatureServer service that shows up in your services list. As for the data layers being edited... I use data layers from my SDE data store, versioned for editing with the option to move edits directly to base (the checkbox in the dialog that pops up when you register a layer as versioned). I am using direct connections to the SDE database. I create a child version that will be used for the editing in my flex viewer in ArcMap. Then in ArcToolbox I use the "Create Database Connection" tool to create a connection to my SDE database **that connects to the version that I am using for editing**. That tool allows you to specify a particular version. I save that connection in a place where my Server can access it. I then start a new ArcMap project and connect to my SDE database and add my layer(s) that I am editing within that version. You may need to start editing and ensure that the layer templates are set up. I typically add a feature of every type that will be edited just to test but also to verify that the editing app is "seeing" everything. I delete these features later before actual use. I then publish the map as a service with Feature Access checked (as described above). After the service is published, I configure the edit widget as well as the main flex viewer config file so that my layers show up. I typically create a separate version of my viewer specifically for editing a particular layer or set of layers. I like to have my users in the habit of consciously editing or consuming data but not blurring the two use cases together. After all, if they are the stewards of the data, I want them to be successful and not inadvertently introducing errors into the data. End users that edit data don't always think about the big picture of their actions like those of us that "do GIS" do. That means their regular, departmental viewer has the layers that they edit but doesn't have the editing function added. If they need to add or change anything with that layer they must load the editor, which I tend to strip down to the necessities for editing and not everyday use. But your specific needs will dictate how you structure everything. If your map services are public, share the link and we can take a look. Maybe something will pop out that hasn't been obvious in our dialog.
... View more
05-23-2014
07:04 AM
|
0
|
0
|
560
|
|
POST
|
Alejandra, Have you published your map service as a feature service? The editing widget uses the FeatureServer rather than the MapServer service. Perhaps you did not check that particular box when publishing your map service? The other thing to look into is whether you have properly set up your data for editing. Is this an SDE data layer or a layer in a file geodatabase?
... View more
05-22-2014
02:32 PM
|
0
|
0
|
560
|
|
POST
|
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!
... View more
04-23-2014
09:56 AM
|
0
|
0
|
1361
|
|
POST
|
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.
... View more
04-23-2014
06:58 AM
|
1
|
1
|
703
|
|
POST
|
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.
... View more
04-22-2014
02:35 PM
|
0
|
0
|
703
|
|
POST
|
...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". 🙂
... View more
04-08-2014
11:21 AM
|
0
|
0
|
2155
|
|
POST
|
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.
... View more
04-08-2014
10:18 AM
|
1
|
0
|
2155
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | 09-10-2024 12:21 PM | |
| 4 | 07-18-2023 08:22 AM | |
| 2 | 11-09-2021 05:42 PM | |
| 1 | 01-21-2020 02:00 PM | |
| 5 | 08-01-2022 09:07 AM |
| Online Status |
Offline
|
| Date Last Visited |
11-24-2025
02:17 PM
|