Project possible? - select feature and show data from connected ones in a form

[PSArcOnlinePSArcOnline]

Hello,

so let's see if the new forum works.

I want to begin a python project. I have a little experience in things like SQL, VBA, PHP and I did a few little python scripts. Before I start this project I would like to know whether it is possible in principle. I know that this is no easy thing but I am willing to learn.

Ok, here is what I want to do.

In my ArcGIS project there is a line shape and polygon shape. In both layers are joint ID fields. So some polygon features are connected to one line feature by this ID.

I want to create an addon that, if a line is selected, show me the data from the line feature in an form view. In that same form the data of all connected polygon features (via the ID) should be shown underneath in a tabular view. If it is possible the values should be changeable.

So is this possible to achieve with ArcGIS and Python?

Thanks for your help and sorry for my English.

[JamesCrandall]

I am not really sure what an "ArcGIS Project" is.  You will have to define that because it's really ambiguous.

Why not just setup a File Geodatabase with your Feature Classes and then create the appropriate Relationship Class (one-to-many) between them.  Sounds like a lot of work to replicate existing ArcGIS components that perfectly meet your needs.

[KimOllivier]

In the help there is a suggested folder structure for a project. If you put your master MXD file at the top, ArcMap will recognise that as the 'Home' directory so that you can keep help, data and tools below the home with relative paths. When you open the MXD the tools and databases will be at the top of the catalog tree.

There is no built-in project file that keeps track of everything like some other packages unfortunately. Even the scripts have to find relative paths with extra code. This is partly because Windows does not recognise the useful relative path notation that is in Unix. You can make the data paths relative with an option in ArcMap if the data is below the MXD.

Geoprocessing packages attempt to bundle up data and tools into a single package for passing around. Which only works for samples or trivial amounts of data. I zip up the whole folder and send it off to be unpacked manually. If I am strict with my code it can work in another location without changing the code or data paths.

[KimOllivier]

Not really the question, but I can't delete the answer in this new forum!

You can build in database relates to relate features, don't use shape files any more!

It is possible to have temporary map relates held in the MXD too.

[PSArcOnlinePSArcOnline]

Thanks for your answers. Even if they are by mistake

I know that I can make relationships between layers and show this with the information tool.

But i try to make something that gives a better overview. So it is easier to get information quickly.

The mentioned layers are within a personal geodatabase. I already did something like this form within Access. If I click the mdb a start form shows up. There I can insert a ID and a second form shows the overview of the data of the line and the connected polygon features. I can edit values there too.

This all works out perfectly. Within Access (using the very same mdb as my ArcGIS mxd).

Now I want to accomplish a similar form directly in ArcGIS. So it is possible to edit the geometry and have a clear view of a specific line and all connected data. There are many values for the line layer and for the connected polygons.

[JamesCrandall]

Personal GDB's are on their way out from what I can tell, replaced by the FileGeodatabase.  Something to consider before spending a bunch of energy on this.

From what I can tell, you want to have more UI elements integrated into the map environment.  Your best option will be to develop ArcObjects COM components or an Add-In version of such.  The latter has more limitations, especially if your attribute datasource(s) are non-spatial RDBMS tables, views, stored proc's, etc..  in which case you'd want to build a more robust complied COM component and installed on users' workstations. This of course means the typical maintenance and install requirements too.

I have no idea where they moved the ArcObjects forum section in this place.  I guess you are supposed to know what to search for rather than just LOGICALLY go to that forum section.

[PSArcOnlinePSArcOnline]

I will take a look at ArcObjects. Thanks.

I read too that ESRI will resign mdb support. Since there is no easy way to manipulate file geodatabase from within Access, I will not upgrade to such a version. I need this on a daily base.

[JamesCrandall]

What's wrong with maintaining tables in a File Geodatabase?  You could implement pyodbc to integrate your Access db, but I think there will always be concerns with drivers and connection strings and ways to manage them over the life of your products.  There's valid reasons to be agnostic to any database, including MS Access.  Why so reliant on Access?

[PSArcOnlinePSArcOnline]

The benefit of using Access is the easy possibility to develop db based programs. At least for us and ok "programs" is a little too ambitious.

On this way users can easily insert data, get information, print reports, export data, perform calculations without using ArcGIS. For some users ArcGIS is too complex to use (and they could produce ​​too many errors).

So the "native" support of geodata in an Access DB is very useful for us. We don't use Access only for some SQL based changes. That could be done in file geodatabaes too.

My goal is to transfer some of these "easy to use forms" directly into arcgis. So maybe, someday, Access is not longer necessary for our geodata based projects.

[JamesCrandall · Accepted solution]

I developed this application for Sarasota a few years ago (it's still in production):

Storm Water Revenue Management System | ArcNews

It's inline with what you want to do but it uses SQL Server database as the attribute data repository and the "GIS code" is really there to just perform some specific spatial tasks.  The bulk of the application is what you'd consider a traditional client/server windows forms application, developed in .NET and utililzed standard CRUD operations entirely with StoredProcedures on the database --- there is zero (0) SQL in the application tier.

The main takeaway here is that, okay it's distributed via ArcGIS as a COM Component Toolbar, but the vast majority of this app is just an n-Tier application like any other.  This is great because it is completely agnostic to databases or front-end distribution.  Thers' a database, Data Access layer, a business layer and a presentation layer --- all of this can be moved and maintained as individual components rather than rebuilding an entire app over and over.

For example, if at any point in the future the powers at be decide to move to an Oracle database then it's not a big deal to connect the applicaiton tier to that database because it is agnostic to any single db.  I just need to alter the DAL tier and connect it up to the new Oracle db.