Latest Contributions by JoeBorgione

Can you give me some tips on how to generate the data for the point locator, please?  I've seen the bit about putting street1 @ street2 in a single field, but that's giving me some pause because of the complexity of handling all the combinations required.  Thanks for the reply! If you are asking about freeways, I don't do anything too sexy; just roll up my sleeves and start adding points where I want them.  Ramps that connect Freeways to Freeways are typically known as Fly Overs, so in the data I manage each of those points follow the convention of FO <Freeway1> TO <Freeway2>.  FO I 15 SB to I 80 EB for example.  You can name them what ever fits your needs.  I do something similar for On Ramps and Off Ramps: ON RAMP <CrossStreet> <FreewayName> ... View more

This is great for navigation, but I can't find the intersection of I-95 and I-64 because they don't actually intersect in the data. But it is common to refer to such interchanges and say "go to 95 and 64 and bear right" for example. So my locator can't find it, but my users will be asked to go there frequently. For these I use a point locator. ... View more

Is this even possible? I've been reading the forums for several days now and no one has an answer.  I want to create an intersection locator based on street centerline data.  Thought using the Dual Range style would be best because my centerline data included all the necessary fields but no go. Also have intersection point data that included individual street names.  The only way that I've read (so far) to make this work is to concatenate the street name field at each intersection for each point so that your table data will read "50TH & FRANCE", and then would need another point at the same location with attribute reading "FRANCE & 50TH".  So for a 4 way intersection you would need 2 points in order to locate the intersection properly. Obviously I'm not going to do that as it would take me 6 months.  ARE THERE ANY ANSWERS OUT THERE?  I FEEL LIKE THIS SHOULD NOT BE SO DAMN COMPLICATED! Push back away from the desk and take a deep breath; no it's not so d*** complicated.  The problem with intersections is they are sensitive to how you set up your locators.  If you specify Prefix Direction, Street Name, Suffix/Type, it wants you to enter the intersection like this: E 50th ST & N FRANCE AVE  (or whatever...) If you want to take shortcuts and leave the extra data off you could try creating aliases of your street names and use the US Streets w/ Alias table locator style.  Or alternatively, composite several US Streets locators in sequence that leave  the various components un-checked.  Be sure to specify  intersection symbols you want to use like : &, AND, @, |, etc; those are pretty standard but you can use what ever you want, so long it's specified in the list. Hope this helps. ... View more

Have you checked with the data provider? ... View more

Yes, and when I try and run say a service area with time as 5 minutes. It highlights my entire dataset. I just checked the summary statistics of my distance field I created from miles and it says the sum is around 1 mile for multiple counties worth of streets. Not sure what the problem may be. Any chance you can post a partial feature class set? The only attributes needed are the shape length in your map units and the speed limit.  It seems like your work flow may be out of whack somewhere on making your calculations.  I'd be happy to lend another set of eyes. In your original post you gave the equation of [Shape/speed] * 60; I suspect that you meant [miles/speed in mph] * 60 to calculate the time it takes to traverse a given segment. ... View more

+1 to Tims comments; the two CAD systems I work with will choke on over lapping ranges.  They also prefer continuous ranges along streets of the same name. As far as accuracy and or precision when geocoding against streets, the best you can hope for is to be accurate.  If you have a range of addresses on a street that go from 100 to 200, you'll geocode house # 150 on the even side of the street in the middle of the block.  Thats pretty good accuracy.  However, what if house # 150 is actually located on the odd side of the street, and is the last house (at 2nd Ave; 200)?  No real precision there. Geocoding against a linear feature is at best an interpolation function of range and segment length.  If you adjust your ranges one digit either way, that may affect the block that address lands on.  However, you're never going to achieve a precise 'hit'.  I'm not a fan of address ranging street segments based on actual physical addresses.  If you want/need that sort of precision, get yourself some good point data. What's especially important in 9-1-1 address ranges is to include the intersections.  Obviuosly there is no structure in an intersection, but in our business, a lot of bad things happen in them:  lets say you have a street calle Elizabeth ST and it starts at 1st ave, crosses 2nd Ave and 3rd Ave then terminates at 4th Ave.  Assuming the local grid values of the avenues are 100 based, the three segments of Elizabeth St should look like this: 100-198  (Low range covers the intersection Elizabeth and 1st ave) 101-199 200-298  (Low range covers the intersection Elizabeth and 2nd ave) 201-299 300-400  ( Low range covers Elizabeth and 3rd AVE and the High range covers Elizabeth & 4th Ave) 301-399 One might argue, " Well, I'll just use the intersection function like &,|,@"  etc.  Sure, but in 9-1-1 typically your CAD needs to assign an address to the interesection in the form of HOUSE-NUMBER, STREET-NAME (like 400 Elizabeth St), so you may as well keep it tidy. ... View more

Whenever I build a network dataset or a geometric network I guess this error: Build Geometric Network failed. The object has been deleted and is no longer valid.  [Network_Net_BUILDER] Unexpected operation [N_1_Props] Unexpected opeartion [N_1_Props] What is going on?  I can't find anything about this in the forums and I'm unable to get ESRI Technical Support as I have to go through IT and IT will not do it.  That makes me a sad panda... - T Mac-and-Cheese-Sandwich Don't you love IT guys that aren't GIS guys? Have to ask; what license level do you you have and what version ArcGIS?  Do you have a network analyst extension license?  Is it turned on? I googled The object has been deleted and is no longer valid.  [Network_Net_BUILDER] and found your post.  (The ferris wheel effect; round and round and round...)  But I also googled Build Geometric Network failed. and there a number of posts. Hope this helps- ... View more

Oh yeah, that would make sense, wouldn't it?  Thank you!  I'm embarrassed I didn't think of that myself, as it seems so obvious now. The address locator I made from the parcel data worked well-- it mapped 72% of the points.  The remaining points were not plotted largely because the parcel data is inaccurate, and it reports some addresses lumped together into one parcel with one address.  For example, I need to map two addresses right next to each other (1100 and 1102).  I believe that there are two addresses to this building because parcels recognizes the building as only having the address 1100, and therefore 1102 isn't being geocoded.  Can you think of anything that I can do to fix this?  My first intuition is that I should go into the parcel data and manually create the missing parcels.  However, besides being time consuming to complete for 150 unmatched parcels, it will not be creating reliable or accurate data. Thanks again for the previous answer, and sorry to bombard you with  an addition question! Unless you are the one assigned to editing parcels, you are better off to avoid going down that road.  In the business I'm in, 9-1-1 dispatch, I like to have 'defendable' data.  For me, it's an elected official (county recorder) that is in charge of editing parcels.  I prefer the legal beagles chase after him; he has way deeper pockets... That said, imho, you have a couple of choices: create a composite locator with your parcel locator listed first and your streets locator listed second.  Since you are not completely thrilled with the way the streets work for you, that may not be optimal.  The second option is to roll up your sleeves and get your hands dirty; manually rematch the remaining 28% to where they 'should' be.  If my math is right, that's less than 200 addresses you'll need to rematch.  If I had a dollar for every address I've rematched over the years, I wouldn't be posting to this forum; I'd own it... ... View more

I was not implying that you did not know what a Table was...no need to get snippy.....just trying to point out that the related object was not another FC with Geometry but rather a table, if that were to affect things. I was hoping for something a little more automatic.... So what you are saying is: that I have to actually figure out what Key field I am dealing with in the main FC Go back to the related table and add a new record and manually type in the ID from the main FC record I am dealing with. Okay; fair enough.  I'll keep the snippiness to minimum... 1. Yes 2. Yes But to elaborate:  it seems as though you have table in some format that has the historical data in it.  You have a feature class with hydrants. And you need to create a relationship where there currently isn't one.  Is this correct? If that is the case, I can not see how you can automatically create a relationship.  However, if there is something, anything, that appears in both the feature class and the stand alone table that can tie a hydrant to one or more of the historical records you can then create the needed relationship.  Maybe an address? Or serial number? Or..?  And if you can do this, I wouldn't necessarily create a relationship class, but rather just a relate in ArcMap.  You can come back to a relationship class later. Assuming have a relate set up in ArcMap; add a field to your feature class called something like MyKey or JoinID etc and calc it equal to to the objectid.  That value will never change and it ensures a unique value.  As you add features sometime in the future, you'll need to calc that field accordingly.  Add a similar field in your historical table; leave them null.   If you are a python guy you can probably use a cursor to step through each feature, select it, use the related tables function to select the appropriate related records, and calculate the the <null> key field in the table to the value specified in the the selected feature class, and be on your way back to the relationship class concept. If you're not a programmer, the grunt work begins. And you'll perform the described workflow manually.  Select feature, related table, calc related records id field; repeat ad nauseum. (But what else are you going to do in a bright, crisp fall afternoon?) You may ask if I have a serial number that is unique to the hydrant, and that serial number appears in my historical data table, why do I need to do this?  The short answer is you don't, really.  But this will just establish a nice clean item to maintain the relationship with, that is used for nothing else.  You'll be able to create your relationship class, add new hydrants (that have no history) and then add history records related to that new hydrant as needed.  Now if there is nothing at all for you to establish the initial relationship, or I've completely missed the boat here, my apologies for wasting your time. ... View more

Yes I can add a new feature to the Hydrant FC no problem and it adds a record to the historical table. But I want to add multiple records to the Historical table relating to that single Hydrant. That make sense? The Historical table is simply a stand alone table...no geometry. And?  That is how it is supposed to work.  If you want to add an additional record to the table, edit it too.  Just be sure to put in the correct value in the key field and you're good to go.  (BTW, yeah, I know what a table is... Thanks.) ... View more

The tables were a major problem.  I spent hours and hours with ESRI because the tables would not replicate to the remote servers.  I also did not like the tables for the lack of search functionality.  I hear that tables are just like feature classes, yet you can not access them with the Find tool.  I am working in a transitory environment with trade people accessing table without the benefit of a designed user interface - everything is temporary, yet we have to keep track of over 100,000 assets including air conditioning units that move daily and are associated with the buildings.  So not being able to use Find to search tables, and then identify and link to the building was a major issue. So back to datasets.  Everything i read placed an emphasis on datasets.  Are you saying that you find a problem with them for replication?  I could easily re-structure without them. I replicate SDE tables to standalone File GDBs almost every day, so it's hard saying what the issue is.  But I use SQl Server 2008 r2... As far as feature datasets go, I'm saying they can create problems in SDE databases. ... View more

Maybe try http://www.asgdc.state.ak.us/ ... View more

To be more specific, I created a new feature class in the SDE database, in the same dataset as the buildings.  I then loaded the table with data from Excel and created a relationship between the new feature class and the building feature class that has geometry, Hope that helps. Using a feature dataset in SDE could be the root of your problems.  I've been been able to replicate through a feature dataset, but I prefer not to. Also, and please don't take offense, but I fail to see the reasoning in a feature-less feature class.  You should simply use a table to store your related data.  That may be part of the problem too. ... View more

Thanks So I created a Relationship class on the Hydrant FC and the Historical Table. Type:  Simple Carnality:  1- Many Notification:  Forward (origin to destination) (Hydrant FC to Historical Table) I didnt setup any rules at this point in the Relationship Class. I can identify and see the related records...I can edit the related records...BUT cannot figure out how to add a new record to an existing FC point.  Any thoughts?  Is my Carnality set incorrect?  How is this accomplished. Thanks See this for an explanation better than I can provide: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//004t00000004000000.htm In a simple relationship, related objects can exist independently of each other. and: In a composite relationship, destination objects can't exist independently of origin objects, so when the origin is deleted, the related destination objects are also deleted in a process called a cascade delete. finally: In simple relationships, getting this correct is critical. This is because when you delete a record in the origin class, the simple relationship class finds the matching records in the destination class and sets the value of their key fields to Null. With respect to adding a hydrant, can't you simply add the feature class to an ArcMap session and then start an edit session on it? ... View more