POST
|
I wouldn't be using float values for relates. That will be very unreliable with rounding errors. The only solution if you have very large integers is to convert them to text strings. This has happened to me in the past with very large prefixes added in Oracle to merge databases creating 13 digit integers with lots of zeros. If you use text then it will still preserve the IDs even in Shape (😂) files. And now BigIntegers are appearing that do not work in most applications, relates or whatever. If Long Integer is not enough, then Text is the best option there too. Census tracts are very long numbers and sometimes they have leading zeros that are significant. Text fields will preserve these.
... View more
06-07-2024
06:04 PM
|
0
|
0
|
95
|
POST
|
Ok, post up the table schema and attribute schema and your relate expression. there are two types of relate, a Map relate (in memory) and a database relate (stored in the database). Are both primary and foreign key fields the same? Are they indexed? If they are characters lots of things go wrong with case, leading or trailing blanks, unicode. It is safest to use integers but now esri has wrecked things with Big Integers that don't always work. What are you expecting with a relate? It is not a join. You can see related records with a popup, or a selection can be transferred with the hamburger options on the table. Otherwise fairly useless for mapping.
... View more
05-23-2024
07:11 PM
|
0
|
1
|
284
|
POST
|
Relates are only possible with internal feature classes, not external data. You will have to either copy the data into a file geodatabase (always a good first step) or you could use python and dictionaries with cursors to get the related data if you are familiar with scripting.
... View more
05-23-2024
03:46 PM
|
1
|
3
|
306
|
IDEA
|
Not fixed in 3.3. Ah well, back to 3.1 so that I can attempt to port workflows from ArcMap! There is a setting in Options/Map and Scene - but it doesn't work for me.
... View more
05-23-2024
03:36 PM
|
0
|
0
|
358
|
POST
|
Good question, I dropped the issue for myself so I never finished debugging for Joshua. Maybe I will have another look to develop more tips with an example.
... View more
04-16-2024
08:07 PM
|
0
|
0
|
643
|
POST
|
line 19. You are changing Connections, not featureclass paths. (I do not know why a shapefile exists in your system!!) I could not find one to test out your script! line 19. The updateConnectionProperties is a search and replace function, so you need to have a string replace option, not a full path option line 9 . If you are comparing paths it is safer to normalize the paths for string comparisons using old = os.path.normpath(old_path). Maybe updateFolderConnections would work better for shapefiles Also you are changing the wrong object source. The project has a separate connections. You should be changing the Layer connection properties.
... View more
03-15-2024
02:25 AM
|
0
|
0
|
768
|
IDEA
|
And now we have BigInteger (64bit) which have appeared since 3.2 that are not interchangeable with Long Integer or Short Integer in many tools. eg RelationshipClasses do not allow them as a valid type for a key.
... View more
02-22-2024
05:32 PM
|
0
|
0
|
631
|
POST
|
I agree with @JohannesBierer that you must not divide up the river, leave it as a line. The Near tool find the perpendicular distance and the xy point at the intersection of the river as attributes which you can then use.
... View more
02-22-2024
01:57 AM
|
1
|
0
|
314
|
POST
|
The limit for a shapefile field is 10 characters. Are you really still using shapefiles? Not really very sympathetic if you are! Maybe you have a path problem so you are pointing at a folder and not a geodatabase. Some example code might help others explain the probably "obvious" error.
... View more
02-22-2024
01:50 AM
|
0
|
0
|
216
|
POST
|
I have found other problems with 64 bit Integers now called BigInteger. Integer fields defined in geopackages and spatialite are now cast by default to BigInteger instead of Integer. RelationshipClasses cannot use them which was a surprise because I suddenly had BigIntegers for every primary and foreign key in my database. I have had to go back and explicitly cast to Integer (32 bit) using FieldMapping on every copy operation so I am not surprised that Pandas needs editing. Just about to do some datetime manipulation, thanks for the heads-up.
... View more
02-22-2024
01:42 AM
|
0
|
0
|
403
|
IDEA
|
When importing data from geopackage or sqlite any field defined as Integer in the DDL gets cast to BigInteger instead of (Long) Integer. This is a new incompatible behaviour since BigIntegers were included (ArcPro 3.2?). There are several tools that do not work with BigIntegers such as RelationshipClasses. It would be helpful if there was a switch to turn off this unwelcome enhancement. There is a switch in Options/Map and Scene - but it doesn't work. The only way to fix the problem is to define a FieldMapping on every copy operation and there are many of these that do not have FieldMapping as a parameter. If the field is readonly such as OBJECTID then it cannot be changed at all. I see another user has used FME to fix this. This is like a reverse single precision / double precision incompatibility! Maybe a switch somewhere in the settings or the environment settings to retrofit a fix?
... View more
02-22-2024
01:25 AM
|
3
|
5
|
855
|
POST
|
ArcGISPro is apparently backward compatible with ArcMap but I have found a serious limitation in the TableToRelationshipClass_management tool when finally upgrading my scripts. ArcGISPro will only accept GlobalIDs or String fields as keys and only String fields in the relation table. What has happened to Integer fields? These were apparently Best Practice in database design for Primary and Foreign keys. Edit: it appears that Big Integers are not supported, Short and Long are allowed, but if a sqlite table is being translated INTEGER type is by default typecast to BigInteger. But these are not supported in Relationship Classes. I have a clone of a large survey database ( 50 tables, 70 GB) that uses Integer for nearly every table which I use in the relationship class definition. There is also a sequence field used to order related records that is integer (of course). Choices: a. I could adopt GlobalID - GUID relationships. This is a lot of additional work, not in the source tables. The GlobalID is readonly and not under my control. It can be changed arbitrarily by Esri tools if they consider the feature is "new" thus breaking the link to the foreign key. b. I could copy the integer keys to strings just for the relates. This is also a lot of work (60 min processing per relate x 5 relations, indexing, rebuild the relate. At least I am still in control and the keys are static. I do not do any editing except for bulk validation, subsets, copies. c. Force a cast of all integers in the entire database to Long instead of Big Integer when translating. Using string values for integers does work but takes over an hour to build the relation class. using GlobalID-GUID pairs is faster at 7 minutes. The proper solution is to return to basics and somehow force the cast to Long everywhere. To do that I found I had to remove deprecated tools TableToTable and MakeFeatureLayer/CopyFeatures with tools from the Conversion toolbox: ExportTable and ExportFeatures which have a parameter to include a FieldMappings/FieldMap/Field expression that allowed me to override the default and change the field_type before copying to a filegeodatabase. I also had to replace the simpler FieldInfo parameter which does not allow type mappings. If you are only doing a couple the interactive tool lets you define the fieldmap, but in Python it is a nightmare of obscure FieldMapping objects. If only there was an environment variable to switch the default Integer type to Long instead of BigInteger.
... View more
02-20-2024
02:48 PM
|
0
|
1
|
672
|
POST
|
Yes you can. Try it. Relates are hard to use. You can get a tree when querying with a popup. You can also select from a table and find related selections with the hamburger at the end of the table view. It requires manual triggering every time [Not like ArcView 3 and Avenue Dialog Designer where the selected records are highlighted, you can raise the selection to the top, not just filter and generally have a much better experience.]
... View more
02-20-2024
01:34 PM
|
0
|
0
|
144
|
POST
|
Have a look at the validation tools in the forms. You can program up a really complex interface with a bit of python programming, have error messages and check it is valid before starting the run. You can even program the whole form up in python so you don't use the wizard at all, I haven't gone to that step myself. Here is an example that analyses our census data. http://www.ollivier.co.nz/support/census2018/index.htm
... View more
02-18-2024
02:09 AM
|
0
|
0
|
276
|
POST
|
Well I think that a list comprehension wrapped around a da.SearchCursor is a very efficient and fast way to extract the features into a more open format. But why do you think that Pandas (a non spatial module) would handle spatial data? I am impressed that it worked at all! Have you considered GeoPandas? That does handle shape columns and provides you with spatial functions. Or maybe use the arcgis module? That has spatial extensions for pandas where geojson data returned by the Python Rest API is handled smoothly. There is another way to extract the features - use Numpy. There is a function in the da module FeatureClassToNumPyArray that translates directly from a featureclass to a numpy array. Maybe you can convert from the numpy array to a dataframe? Finally there are Geometry Objects. These are in-memory arrays of the geometry from a featureclass that have a complete set of spatial operators built in. Every spatial tool in the toolbox has an equivalent function for pairs of geometry objects that do not need an advanced licence. You can write a complete ArcGIS clone using a Basic licence. I do this for selected operations if needed to be restricted to a Basic licence or if I find a faster way by short-cutting the search.
... View more
02-18-2024
01:58 AM
|
0
|
0
|
256
|
Title | Kudos | Posted |
---|---|---|
1 | 05-23-2024 03:46 PM | |
3 | 02-22-2024 01:25 AM | |
1 | 02-22-2024 01:57 AM | |
1 | 03-15-2023 06:41 PM | |
2 | 03-11-2023 03:47 PM |
Online Status |
Offline
|
Date Last Visited |
06-12-2024
02:24 AM
|