|
POST
|
If you drag and drop a database table into ArcMap vs. using the Add Data dialog, the drag and drop process adds a percent sign to the table name. The Add Data dialog process does not. I found this bug at version 10.2 while using the Flex Viewer. At first I thought it was a Flex widget issue. That was not the case. I opened a support ticket and we eventually found the workaround. Apparently there is a bug that was logged at v. 10.1 regarding this. [#NIM093503] Apparently the bug has not been resolved. FWIW, ArcMap seems perfectly happy with the percent sign. Publishing a map service--or maybe consuming said published map service--is where the issues creep in. Bug report: http://support.esri.com/bugs/nimbus/TklNMDkzNTAz My initial forum post regarding my issue along with multiple updates: https://community.esri.com/thread/90592 Doesn't solve the original question but answers the "percent sign in the table name" question... Brian
... View more
07-19-2016
09:49 AM
|
3
|
2
|
6868
|
|
POST
|
Patrick, ArcGIS 9.3.1 was a very long time ago for me and I no longer have a machine with that version installed. As I mentioned, I am not even sure that what I offered up as a possible 9.3.1 solution is even correct. My suggestion would be to compare the "standard" locator styles installed on your machine with those from the zip file and see what differences there are.
... View more
05-05-2016
08:05 AM
|
0
|
0
|
1815
|
|
POST
|
@Patrick Corley: In response to your question regarding a 9.3.1 version--maybe? It's been so long that I don't remember what the format for those styles should be, but I have in my archive a .lot file that I believe was the "pre-version 10" style. I am attaching it here but have no way of checking/testing to see if this is actually what you need. Please respond here with either success or failure in using the attached file, simply so others can have a status update regarding the usefulness or uselessness of the file. Brian
... View more
04-11-2016
01:03 PM
|
0
|
2
|
1815
|
|
POST
|
Jared, A couple of comments regarding the lock/in use message you received when attempting to add a field: You must add the field when connected as the data owner. It will then appear in all versions (may need to refresh the version). It appears that this feature class may also be utilized in one or more map services (just a guess given the 'IMS' user indicated in the lock message)? Also, users of other child versions could also be working with the feature class at the time (though your lock message doesn't seem to indicate that). That complicates things because, as the message indicates, you cannot make schema changes when the layer is in use or otherwise locked. I run into this occasionally. At those times I must briefly stop my map service(s) that contain the relevant feature class, add the field (as the data owner), the start the map service(s) back up. It helps that I manage all of the data, have the ability to connect to the database as the data owner, and can usually plan the brief 'blip' in map service availability by doing it at an off-peak moment of the day. Christopher's suggestion to use the Generate Near Table sounds like a great solution for you--if you have an Advanced license. Sadly, many of us do not so we must resort to other methods.
... View more
03-29-2016
08:02 AM
|
1
|
1
|
3299
|
|
POST
|
Jared, You may be making this more complicated than necessary, based upon your response to Jake with your list of actions thus far. All of the comments so far are useful, though offer up a few different approaches. The Spatial Join tool is your best bet for getting the PIN info into your building footprints. You don't say whether your existing building footprint layer must stay or if you can simply remove and replace it with an updated version. Jake's comment regarding joining the Spatial Join result back to the original layer is operating on the assumption that the existing layer must stay. I will second Chris' warning about using the OBJECTID as a unique ID, as you have no control over the system reordering the IDs, so the suggestion for creating your own unique ID would be useful IF the existing layer must stay. But, let's keep things simple and assume that you can simply replace the existing buildings layer with the end result new buildings layer once you've finished processing. Set up your attribute fields in your buildings layer however you want or need them. This presumably includes a Parcel PIN field. I suspect this is already done. Fire up the Spatial Join tool from ArcToolbox. From your original post, you want to attach the PIN TO the building footprint. That's the "clue" for deciding, in Spatial Join, which is the Target layer and which is the Join layer. Set your output feature class (this will be your new buildings layer). Keep all Target features (because you set up your buildings layer in step 1 the way you want it. In the Field Map of Join Features box, delete any fields from your parcel layer (Join features layer) that you don't need (don't delete any of the buildings layer fields!). If you are only transferring the PIN, delete all of the parcel layer fields except the PIN field. This will save you from having to delete the extra fields later. The Intersect match option usually works well. I'm assuming that your building footprints don't straddle multiple parcels and are fully within a single parcel. Click OK and run the tool. Your new feature class will be created. In ArcMap, open the attribute table for the new feature class, right click the PIN field you created in your buildings layer (the empty field) and select Field Calculator. Find your parcel layer PIN field and double-click it to put it into the query box. The query effectively is 'BuildingLayerPINfield = ParcelLayerPINfield'. Click OK and whatever value is in the ParcelLayerPINfield will be transferred over to the BuildingLayerPINfield. If you had other info from the parcel layer that you wanted to transfer, perform a similar operation on those fields. Delete the ParcelLayerPINfield from your layer, as you don't need it any longer now that the info has been transferred. Delete any other parcel layer fields you may have kept. The end result should be a buildings layer that contains only the attributes you originally created. This buildings layer is now your new buildings layer. You can get rid of the old one. That takes care of the PIN field. It sounds like you can do some group selects to populate other fields. Adrian mentioned the Transfer Attributes tool. I use it in certain workflows, but keep in mind that the tool is used in a one-to-one fashion. After setting up the fields you want to transfer, you select a source feature and then a target feature and the mapped fields' attributes are transferred. You could use this for the parcel PIN but you stated you didn't want to do them one at a time. That makes it the "wrong" tool for your current purpose. I only have a cursory knowledge of the Attribute Assistant tool, so I can't comment regarding its usefulness in this context. Brian
... View more
03-22-2016
10:24 AM
|
1
|
4
|
3299
|
|
POST
|
Adrian, Your statement: "I suppose my company does not know exactly what we need or where we think we are going..." is a huge red flag to me! It's great that you want to jump in and install AGS Workgroup to see what you can do with it, but that sounds like you are experimenting with a solution trying to find the problem(s) that it will fix for you. That's the wrong approach, particularly if it means spending money on a server (physical or AWS). Here is a link to the ArcGIS Server functionality matrix document. In the "How to use this document" section it states that "This document is a guide for helping you determine the edition and capacity level of ArcGIS for Server that best fits your organization." I wish it incorporated a "hosted data on AGOL" option into the comparison. I realize that after digesting this document you may realize that [once you know] the things you need AGS to do may require an Enterprise (i.e. more expensive) license and may thus be a 'non-starter' but sometimes the honest truth is ultimately the least painful. I honestly think that AGOL and hosted data may be a viable solution for you. I haven't spent an appreciable amount of time on AGOL so I can't debate your comment regarding labeling. I do know that originally AGOL was horrible with labeling but I believe that has been improved with subsequent updates. I'm not sure what your AGOL subscription looks like with your licensing of AGS Workgroup and whether you have any credits available as part of it, but you may want to experiment with AGOL first and upload some sample data of yours to work with. I think it is something like 1 credit per Gb of data per month for Esri to host? Even if you don't have a pool of credits as part of your licensing, 1 credit equates to roughly 10 cents (according to our regional office folks at one of Esri's seminars), so a few months of hosted data probably wouldn't break the bank and likely would be cheaper than purchasing a server or AWS. Also, you control what "stuff" gets permissions to be viewed publicly so you CAN keep certain things private if you want. Admittedly, we are all offering advice/suggestions based upon a very small subset of info regarding your actual needs. So our suggestions/advice may be questionable in certain contexts.
... View more
03-14-2016
08:44 AM
|
1
|
2
|
1636
|
|
POST
|
Adrian, Previous posts have pointed you to some decent sources of info. You don't provide much info regarding what you are needing the map server for, so we can only speculate regarding your true needs. You mention you already have Server Workgroup but we don't know if someone at your company got talked into buying a license and now you need to figure out how to implement it or if it was purchased by someone prior to you with more knowledge and they left before implementation and you are assigned to pick up where that person left off but with less knowledge. Depending on your needs, you may be able to just use ArcGIS Online and pay Esri to host your data. You could get rid of the Workgroup license cost and put it toward AGOL and hosting. You already mentioned Amazon Web Services, which could save you from managing the hardware but I don't know how your existing Workgroup license might be leveraged (does it just transfer?). Both of these scenarios could save you from the hassles of maintaining hardware. Your overall knowledge level, such as with relational databases, should also be taken into account. It's evident that you have a willingness to learn but do you have the time and resources to do so? And what are the expectations of your employer? Do they understand where you are on the knowledge arc for Server or do they believe that because you "know computers" you automatically know Server? I have co-workers who believe I am a Windows desktop support specialist simply because my desk was once in IT (my job has always been as a GIS Coordinator). I call it "abilities by association". You also mention needing some secure services, so maybe your data is sensitive enough that you don't want it hosted off-site. Someone mentioned that Portal (should you decide to host AGOL in-house) is recommended to be on a separate server. You say you work for a small company. Depending upon how beefy your server is and exactly how small your company is (i.e. how many users are expected to be hitting the server/Portal at one time) you may be just fine with both on the same box. I think the book that was mentioned would give you a solid contextual knowledge of Server--enough to be able to ask the right questions of Esri reps or maybe a consultant hired to take your use case and recommend a setup or course of action. Rebecca's comment regarding an EDN subscription could make sense, but once you settle on a possible configuration, you may consider asking your Esri rep to provide a six month trial license (if you don't already have the necessary licenses) to test the viability of your decision. I'm not sure if Esri does that much anymore but it would be worth asking. BTW, SDE is part of ArcGIS for Server Standard (Workgroup or Enterprise), so you just need to have a compatible relational database (yet another additional cost/license and possibly another server box).
... View more
03-08-2016
11:01 AM
|
1
|
1
|
2936
|
|
POST
|
Peter, We don't use multi-line input--only single-line--so I've never noticed an issue and of course never bothered to test it with multi-line input. And you have confirmed that single-line works correctly. So I don't believe I can be of much help. Have you tried the version that Brad Niemand (Esri) created to see if it has similar issues? I really only added fractionals and units to an existing locator--and Brad actually tweaked it under the hood to fix some remaining issues because the available documentation isn't extensive enough for me to know/understand what those changes should be.
... View more
02-10-2016
08:47 AM
|
0
|
1
|
1440
|
|
POST
|
Ahmad, It appears that you control some of these layers (map services) and others you simply consume? That fact may make my suggestion a non-starter but... Might you be able to convert the labels of the layers you DO control into feature-linked annotation and edit that anno to conflict less with the layers you don't control? You mention layers with 250K features, so what I suggest isn't something that can be solved with a simple click of the button, but that might be one of your very limited options. Your experience is the downside of serving up a multitude of data in separate map services. Sometimes the combination doesn't work very well. I run into the same issue with various combinations of map services I provide my users. With so many possible combinations of map services that can be viewed at once, there is bound to be conflict that cannot be easily resolved.
... View more
09-30-2015
09:50 AM
|
0
|
0
|
1705
|