2

I've inherited some scripts that (to my mind) "abuse" geocoding to position points based on a LocationID field. As the name implies, this field is a unique ID that really doesn't need to be "fuzzy matched"; either it matches or it doesn't. Besides that, using the geocoding tools for this process is painfully slow; some 5 minutes or more to geocode less than 100k records.

I've tried using joins, with not much luck:

  • Joining the tables to the reference points with AddJoin: with "KEEP_ALL" results in all the points, some with no data; with "KEEP_COMMON" results in only matching points, but loses data where multiple rows have the same LocationID.

  • Joining the points to the tables with AddJoin results in tables, not point features.

  • Joining either way with JoinField is even slower than geocoding, and has the same issues as above.

  • None of these methods produces a new feature class as geocoding does; that takes a CopyFeatures either before or after the join. (SpatialJoin does, but it's out of the question since one input is a table....)

So, is there any faster way to do this using GP tools – if not, that might explain why it is the way it is – or should I look to a lower-level solution (arcpy.da or the like)?

(To clarify, the output I'm looking for is a point feature class: each point has data from a row in the input table, but there may be multiple points in a given location.)

|improve this question
1

It is about transferring points coordinates to table. You might use this process:

  1. Add X and Y fields to points' table
  2. Join above to TABLE using common field. Calculate similar field e.g. [XN]=Points!X
  3. Export joined table to new one.
  4. Create XY event table from output at step 4. Based on your Q you'll end up with duplicate points in some cases.
|improve this answer
  • In fact the point features we're using to geocode come from a generated event layer, so maybe I could just have a separate join-and-make-event-layer for each table? And yes, I expect duplicate points, but with different data. – criptych stands with Monica Feb 23 '15 at 20:41
  • Yes, it is likely you've got XY fields already in your point layer. Join by attribute is always a pain in ArcGIS with real life datasets, be ready to wait.. – FelixIP Feb 23 '15 at 22:12
  • Well, it does work, so I'm accepting the answer. Unfortunately it's really not much faster -- that join is killing me -- so I will stick with geocoding for now and just try tweaking the parameters some more. – criptych stands with Monica Feb 27 '15 at 19:47
  • As I mentioned f.calculator IS pain. arcpy.da cursor is far more superior, you start with creating dictionary on parent, then iterate through childs record with update cursor on x and y field. Search site – FelixIP Feb 27 '15 at 20:53
  • So you mean to cache the coordinates in Python instead of using a "true" join? Can't believe that didn't even occur to me -- I'm already using a similar technique in another tool. sigh Thanks again, I'll try it when I'm back in office. – criptych stands with Monica Mar 1 '15 at 0:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.