Latest Contributions by JesseMardis1

‎08-09-2023

Thanks for your help... The solution here was to export to a shapefile, add the full address field, run the field calculator on the shapefile, then reimport. We never figured out why the database feature class seemed to be adding extra space. It's not an efficient solution, but it is a solution. Only took 3 months to circle back to this but I wanted to advise anyone reading that the original issue persisted and we had to do an inefficient workaround. A solution is a solution, I guess.

‎05-30-2023

I just tried this. It actually wanted the syntax to be like ([field1]).strip() but I gave it a shot. It actually added more spaces than it did before. 164 Weller Ln became 164 Weller Ln. Good idea all the same. It's as if it is putting spaces in for the street number suffix, prefix direction, and prefix type no matter what.

‎05-24-2023

Good call. I checked this and found that there were no rogue characters in those fields in the database and all the empty cells are truly null. Oddly enough, I found that there were spaces in all of the empty cells of the shapefile. Not sure why those would be there on export, but they are. Presumably, they get appropriately skipped because of the None, '', ' ' bit of code. The database feature class appears to have no extra characters, though.

‎05-24-2023

We created an expression in field calculator that concatenates individual components of an address into a full address field. When I fill the code block and hit Apply, the output is what I would expect. When my coworker performs the same actions, his results have additional spaces and not in any recognizable pattern. Randomly, there will be extra spaces before and after various bits of the address. After a while of investigating the differences in our actions and environments, we realized that he is running the script against a feature class in an enterprise database while I was testing it on an exported shapefile of that feature class. Aside from that, the code is the same, the tables are the same in terms of data type, precision, etc., and we are both using ArcGIS Pro. The script works as intended on a shapefile but adds spaces when run on a feature class in a database. Example - When I run the script on the shapefile, I get "1984 MONKEY DR BLDG A FL 2 UNIT 26" When he runs the script on the feature class, he gets "1984 MONKEY DR BLDG A FL 2 UNIT 26" with extra spaces Does anyone know what could be causing this? I've included a screenshot of the field calculator.

‎12-02-2016

Allison, thank you for your reply. I like the idea of doing the migration in chunks rather than "biting off the whole LGIM." I'll give one dataset a try and see how it goes.

‎11-30-2016

I am a new LGIM user in city government that is just getting started in the implementation process (or attempting to, anyway). The intent is to gradually move all city data to the model. Currently, all of our data is in SQL Server and we would like it to stay there. Does anyone have any experience/tips on the best practice for implementing LGIM in SQL Server? For example, should I create a LGIM local gdb, move our data there, then port to SQL Server or should I create the LGIM in SQL Server and manipulate the data there? My apologies if this question or a similar question has been asked. It would seem the most difficult step in implementing the LGIM is actually getting started. Any helpful tips on best practices or good beginning steps would be appreciated as well. Thank you!

Online Status	Offline
Date Last Visited	‎04-16-2026 11:13 AM

My Ideas

Latest Contributions by JesseMardis1

Re: Python in Field Calculator generates different output when ran on shapefile vs. enterprise database feature class

Re: Python in Field Calculator generates different output when ran on shapefile vs. enterprise database feature class

Re: Python in Field Calculator generates different output when ran on shapefile vs. enterprise database feature class

Python in Field Calculator generates different output when ran on shapefile vs. enterprise database feature class

Re: Local Government Information Model in SQL Server

Local Government Information Model in SQL Server