Latest Contributions by KimOllivier

Can you have another go at formatting the code? It is unreadable. My strategy for the joinfield tool is Don't. Especially if it is a large table. You will have trouble with joins across databases, and if it is in the same database, use a database join. Instead I extract the data I need using a dictionary of tuples of the required fields using a SearchCursor dictionary comprehension. Then add some fields to the target, or a copy and populate using an UpdateCursor. This is always faster, reliable and works across databases. It does not need an index because a dictionary has a hash table underneath the hood. To allow for missing values use the get function with a default of None. ... View more

Perfect! Just what I was looking for. Something that actually works and answers the problem. There are a lot of false leads in this thread that I had already tried. ... View more

You need to share more of your workflow for us to comment. My initial though is "Why do you need to run many parallel processes?" Why not do them all at once? It feels like you are 'Reinventing GIS'. By this I mean that the spatial tools are designed to run on whole datasets, so running a tool for each feature or even a group is very inefficient, if you are doing that. I can't tell. Partitioning is a good strategy if the data overloads the tool sometimes and in theory you could run in parallel, but I find that the partitioning is so successful that i just run the tool in a loop of a few partitions (not thousands) is good enough. My goal is to run the tool in a few minutes so that the total time is still reasonable. I personally do not use Modelbuilder because I do not have enough control of intermediate results. They are always written out to a scratch geodatabase. In Python you can hold selections as views, use SQL queries, store sets in python dictionaries that are hashed arrays, use spatialite which is much faster for some operations using SQL and generally avoid some of the elegant but unscaleable standard tools. For example avoid any processing with a joined table. I think that a change of approach can make you process run in the time to have a cup of coffee. ... View more

I would like to see a little NLP to extract an address from other clutter to improve the match rate. At the moment a person's name in the address such as is put on mail labels confounds the very strict requirements of an address string. There are open source packages that do this very well that I have experimented with. They need a body of examples to be trained on, but that isn't very hard to do once. Here is an example: GitHub - datamade/usaddress: a python library for parsing unstructured address strings into address components  ... View more

The SIDE is required. It would help if there was a sample reference dataset or at least some documentation of the allowable flags for these codes. I doubt if it will appear, so us users will just have to reverse engineer the options and document them here and on Stack Exchange. The SIDE field is REQUIRED in the locator builder, so something has to be populated. They are not intuitive. I had a fruitless search in the help for a list of codes. I then searched the configuration file and can guess that Parity can be L, R, M for perhaps Left, Right, Mixed. So what would SIDE use? Maybe the same but a D(ual) might be an option. Perhaps BLANK is allowed, but never NULLS I suppose that is because someone might be using a shapefile still where nulls are not supported. The default output of a locator is still set to shapefile. ... View more

I would like to suppress some fields, reorder and change widths which can be done , and save the format for subsequent restarts. Having to do it again every time is a pain. ... View more

If you are going to use Python to calculate fields with lots of logic then it is much easier to use an UpdateCursor. The FieldCalculator wraps a cursor around your expression anyway so it is the same thing. I regard the FieldCalculator as a prop to use in ModelBuilder only. The benefits of using a cursor are many: The logic is easier to write and understand It is easier to test the result and debug You can handle exceptions and unexpected input The syntax is simpler If you are using a join, then use a python dictionary instead for speed. with arcpy.da.UpdateCursor(feature_class,['A1',' B1',' A2', 'B2',' C']) as cur:       for row in cur:             if (row[0] == row[1] and row[2] == row[3]):                row[4] = "A AND B IDENTICAL"           else:               row[4] = "OK"          cur.updateRow(row)‍‍‍‍‍‍‍ ... View more

Have people noticed that these statistics do not appear until metadata is built for the geodatabase and needs to be refreshed to get featurecounts and dates? That is the clue on how to get these details programatically. You can't read the imbedded metadata easily because it is stored as a BLOB, but you can export it to XML and then read it with Python. All the tools are there to export metadata and the standard python module Xtree can extract what you need. No need for ArcObjects at all. 1. arcpy.management.SynchronizeMetadata(....) 2.arcpy.conversion.ExportMetadata(...) 3. import xml.etree.ElementTree as ET   tree = ET.parse(xmlfile)   [get required elements] ... View more

I don't think it applies to images that are always rectangular. So for your case create a bounding box and tile it into less than the maximum size. Better still contact the vendor and get a quote for providing the area you want. They probably will do a custom area. My thought experiment was to simply divide up an irregular but convex polygon into segments from the centroid. We know the area of the segment so we can create triangles from the centroid to the boundary vertices. you keep adding up the triangles until you reach the limit and then draw the combined shape. For 4 parts the segments would be quarters. I know for large numbers the shape would not be squarish. This could be helped by cutting out a circle in the middle and then do the same process, subtracting off the centre segment. Then there would be n -1 equal areas and one circle of the same area. The areas around the ring would have roughly 4 sides, maybe the circular side could be simplified to a straight segment. ... View more

This seems to be an unanswerable question if it is still going after 5 years! But it inspired me to think of a solution that is modelled on the discovery that the earth sweeps around the sun on an ellipse at different speeds but a constant swept area. I know people had in mind rectangular forestry plots but that is never going to fit into an irregular polygon. Without the restraint of a grid (from previous failed solutions) there is an apparently trivial solution. So this is my idea that seems easy to implement. Why not simply divide the area into n segments? Each segment will have area = total_area / n. There will not be any left-over areas. Start by selecting the centre, say a modified centroid. Then sweep around the boundary adding up the cumulative area until you reach the limit for a segment, draw a line and restart. I can see an exception with some shapes that are so re-entrant that there is not a straight line to the centroid, so they would need special handling such as splitting into convex polygons. With geometry objects in arcpy the calculations can be very fast with a python function that iterates over the boundary vertices. Each step is a simple triangle with an easy area solution, just keep adding until you get to the limit. If the vertices are too widely spaced, interpolate or densify the boundary before starting. So you don't like the shapes? Why not, for a small number, say 4 they will be almost a rectangle anyway. Maybe for a very large number you could cut out the centre say using a circle and have n-1 segments around the donut to prevent sliver shaped areas. Hint: Surveyors use the Double Difference Area equation to calculate the area of a traverse with only one division operation by 2. Anyone up to the challenge to provide a script that runs in a short time? ... View more

Do you need a geometry AND a wkt version? Surely one will do. You would have to be careful to get the one in the list. Would it not be easier to just write  row[1] = objectdict[row[0]] where the objectdict is a dictionary of shapes indexed by ID I am trying to help you debug your code, so I would put in a lot of print statements that confirm you do have a geometry and it is in the right row element by printing out a WKT representation as you go and then break after the first one. If you only put up pseudocode you are hiding your problem with your assumptions on where the problem lies. It would be much better if you posted your real code. ... View more

Rather than a list of geometries a dictionary of geometries is more direct to insert. ... View more