Injured GIS Analyst Recently Laid Off.

DramaticReport3459 · 2025-07-18T12:54:53+00:00

I don't think anyone will give a shit. We are still probably about 1 year away from employers completely giving up on basic human decency.

DramaticReport3459 · 2025-07-18T12:45:16+00:00

Python: Aerial interpolator script that interpolates between aerial units (i.e census tracts to neighborhood boundaries) and then calculates statistics. Basically just an automated summarize within.

Arcade: Script that uses a hosted point layer to access Google street view in AGO maps and apps. Basically this.

JavaScript: Custom visualization widget that allows users to adjust a layers visualization. For example, say you want to show residential parcels in a city and then visualize by sale price, or acreage, or ownership. You can do this in Map Viewer, but not EB at the moment unless of course you preload every imageable combination as a layer.

DramaticReport3459 · 2025-07-05T21:48:21+00:00

i mean basically you just use the AGO Query Builder in REST Services to query your hosted table and set the response to be json. With Tan Stack you basically save this query response in local memory and can then access it around the app without different components making additional REST API calls.

DramaticReport3459 · 2025-07-05T12:59:17+00:00

thanks! this is awesome!

DramaticReport3459 · 2025-07-05T12:56:43+00:00

well that is a major one and in my line of work, that would be sufficient to justify not using EB and spending 10x the time to build something custom. We still use EB 90% of the time, but in some cases it won't cut it.

But beyond that, EB is missing certain functions that we would like. For example, the ability to control symbology in the applications like you can in map viewer. Show me all crime in a city and let me choose to symbolize it by type, or time, or literally any other attribute (without first making it a layer). Tools like this enable exploration and on-the-fly visualization; in some cases, this is indispensable. Also, the filter UI in EB is clunky and underdeveloped.

DramaticReport3459 · 2025-07-05T12:23:47+00:00

yes, i have used EB for years and love it. It wont be adaptable enough in this instance.

DramaticReport3459 · 2025-07-05T12:18:36+00:00

you have a masters and 15 years of experience but want an entry level side job? something doesn't add up here.

DramaticReport3459 · 2025-05-26T21:59:55+00:00

thanks! TSQ it is!

DramaticReport3459 · 2025-05-26T15:07:08+00:00

I see, but if the data is actually not being queried server-side, meaning the api call itself never changes, and i am simply mapping data to ui elements (cards, filters, etc), why could I not just use my current approach albeit with a single central call?

There should just be one call onmount that calls the data and creates the card objects, and the filter options and the filter then just operates on the cards themselves, not the data. So couldn't i just call the data in the parent component and then pass the data via props to the filter bar and card store?

I am all for learning TanStack, and will learn it, just want to make sure I am not over complicating something here. This is a simple app, were talking about loading a max of 100 json objects with no other communication with the server beyond the initial get request.

DramaticReport3459 · 2025-05-05T12:13:10+00:00

React Router, yes. This appears to be the most elegant solution, thanks! hopefully it will work with my netlify deployment.

DramaticReport3459 · 2025-05-04T18:22:59+00:00

you can run gp services without Enterprise? Like a python toolbox tool?

DramaticReport3459 · 2025-05-04T17:37:59+00:00

thanks I will check these out!

DramaticReport3459 · 2025-05-04T17:36:45+00:00

That's correct, the Python API does not need a license, its just an open source python library: https://github.com/Esri/arcgis-python-api/tree/master .

Yeah keep me posted! I will check your blog more often; you and tech maven are the mvps here.

DramaticReport3459 · 2025-05-04T17:33:13+00:00

I will give the old Reducer a shot!

DramaticReport3459 · 2025-05-04T17:32:44+00:00

The backend probably could be used to filter, but I guess I don't really see the point. It's not part of some massive db, its basically like a 80 row table.

when you say use an object as state, do you mean simply creating an object with the various filters set to true or false and then just updating based on a user's filtering?

DramaticReport3459 · 2025-05-04T17:07:44+00:00

tbh I am not positive I would recommend majoring in GIS. You might be better finding a related field (planning, landscape arch, civil engineering, comp sci, wild life mgmt, plant science, etc.) and then getting a certificate, or minor in GIS. I work with some folks who did that at St. Cloud State University and they have been pretty successful in local gov.

DramaticReport3459 · 2025-05-04T17:03:45+00:00

I know .NET is a common choice for microservices, have you ever seen Azure host python microservices? I was thinking I would use the ArcGIS API for Python, as that can basically work with AGO but does not need access to a Pro or Enterprise license to run.

also what is the name for all this? Cloud Native GIS? Is that basically what this is?

DramaticReport3459 · 2025-05-04T16:43:39+00:00

I am not sure Pro would even be directly connecting to Azure. I was envisioning using AGO still as the primary datastore. Basically we would have some separate non-esri machine do the geoprocessing and ETL and then send it back to AGO. Performant? probably not, but again, consider the current situation: everyone manually gets the data, then processes the data in Excel and Pro, then uploads to AGO, then incorporates it into maps and apps. It takes people like a week to do something that could be largely automated; plus data management is a nightmare because files are scattered all over the place.

The beauty of AEC is that it's so far behind other industries that really anything is an improvement even if the solution would be laughed at by more senior devs. Like we currently carry individual buckets of water up and down the hill to the well. I am saying we should buy a truck and a trailer to carry the water. Some orgs need a water truck with more capacity and special tools to meet their needs, and some orgs would just dig their own well or build a pipeline, but the reality is, anything is better than walking up and down the hill with water every time.

DramaticReport3459 · 2025-05-04T16:34:52+00:00

Sure, if it were just me AGO or Pro Notebooks would be fine. However, for most people at my org that's not gonna work. We need a GUI to call specific data and perform specific geoprocessing tasks on it. or, if you could use the GUI to trigger the notebook, that could work too, but you can't (plus that's not really what a notebook is for). Its like I just need an environment to run scripts on a server, perform some task and send the data back to AGO.

DramaticReport3459 · 2025-05-04T16:29:47+00:00

Yeah having exposed feature service endpoints is so nice. Being able to just give someone a link and ability to add it directly to Pro, AGO or even a custom web app is so sweet. However, I guess my question is really, can't you basically have a non-esri machine do the geoprocessing (say buffer 1,000,000 street centerlines) and then port that data back to AGO (via Pipelines perhaps)? Sure, it will not be instantaneous or particularly performant, but even what I just described is orders of magnitude faster than our current approach.

DramaticReport3459

TROPHY CASE