[Feature] Project Extent
Closed this issue · 14 comments
As a Project Team Member, I want to create and maintain a geographic definition of my project so that I can
- perform analysis based on project geometry
- see/share a map-based view of my project
- identify proximate or spatially-similar projects
In-scope:
-
Project-level geometry (hand-drawn shape of project)
-
Storing GIS data in AGOL
Out-of-scope:
-
Component-level geometries
-
Storing GIS data (aside from Feature ID) in Moped
Additional notes:
This feature is not a must-have in the sense that it was requested by AMD in the initial version of Moped, but our proposed workflow for entering in a new project is New Project (name, brief details) > Project Staffing (assign staff to the project) > Map Project Geometry (this feature). We were going to require project geometry for every project in order to ensure that projects will appear on a map view for Moped, as this is a key request from anyone involved in planning/coordinating across city stakeholders.
Key question: should features that will show up as "required" later be included in the initial MVP to prevent users from getting comfortable without the extra step fo mapping?
for discussion: rather than drawing project geometries, i want to propose that users select one or more location polygons.
@johnclary — you proposed using @frankhereford's polygons earlier; is that still where your head is at? @JaceDeloney pointed out that doing so would stave off modifiable aerial unit issues.
@amenity yes. because:
- that should give a generalized-enough area to describe the project work, while standardizing the shapes
- it makes it easy to join project data to other things we capture in those same polygons (e.g. crashes)
- it adds a wider user base of people looking at those polygons and helping to flag issues with their geometries (they're very good but i believe there are still quite a few issues around frontage roads/highways)
it will require a change to the data model. rather than storing a single feature ID, we'd need to store an array of location poloygon IDs
on the other hand, it makes the GIS interface and integration easier. there's no drawing of shapes at all. no need to login to arcgis online.
No drawing of shapes at all. no need to login to arcgis online.
😍
Using location polys, project geometries would look like this, for example:
So the locations polygons covers creating/editing, but for visualization purposes I think we're still going to need a dedicated map layer of Moped projects.
This layer would contain features that look like the one pictured above, with each project feature having a single geometry that is a union of all of the location polygons that it references.
Whenever we want to view all projects on a map (e.g. for #3672), we would use this layer. At a minimum the layer could have just a single attribute column for Project ID, although it might be handy to store other project data in this layer, e.g. project name, description, etc.
It should be pretty straightforward to create/maintain this layer through an ETL process, and we'd want to trigger this ETL whenever a project was created or it's associated location polygons were changed.
If this all makes sense and sounds agreeable I can create some issues for it.
Really like the improved usability and cleaner data we will get by doing it this way instead of having everyone be artistic.
The downside that comes to mind for me is that overlapping polygons are a little clunkier to deal with from a cartographic perspective. Offsetting polylines for visualization is standard, design-wise, and pretty widely supported.
One can wrangle overlapping polygons to display well in certain cases, but I can't imagine how this would work for line-like features that precisely overlapped.
Just as I say that, I guess something like this could work just as well on roads... Would be like a tidier version of Strava heatmaps:
This is fine for visualizing general project density, but if we need to represent categories of projects — e.g. differentiate using colors, this approach won't work.
@johnclary if we repurpose project components (what Nathan calls facilities) as these polygons to roll up into one project-level, we actually are set up for both your proposal and what ATSD ultimately wants. Of course we wouldn't start with the level of detail that Nathan stores at the component-level, but I do love this suggestion because it requires less work down the road when we add additional features.
In my understanding, components, né facilites, are much more granular than these polygons...
@zappfyllc, are you suggesting that every facility would map to whatever polygon contained it? So for an intersection with 4 crosswalks and 8 ped ramps the project would contain 12 identical polygons each representing a unique component?
@amenity Facilities are definitely more granular as a dataset, but I'm not under the assumption that every single facility gets hand-drawn as lines in arcGIS. At least, based on what I have (see screenshot), many of his facilities don't have an AccessLength, which I believe is a calculation of the length of the shape in arcGIS. My assumption has always been that he stores project facilities in Access as means of driving implementation cost estimates and identifying "assets" on the ground but not every single facility gets drawn/mapped because of what you're referencing (too much repetition/overlap, granularity, etc.). It appears most of the facilities that are actually given a location have a very clear relationship with the street layer and may be relatively easy to relate to location polygons if they already exist for a given project.
Screenshot of a single project's "facilities" or "components" in Access:
The reason I made the comment is that @johnclary's picture of the polygons is remarkably similar to what Nathan has showed me in the past for facilities (I can't tell you how many times Nathan pulled up MS Paint and started drawing shapes/lines). Obviously @johnclary isn't addressing the tabular data with this proposal, and I'm not suggesting we tackle any of this immediately at all, but I think there may be enough functionality if we're allowing individual polygons to roll up into an overall project shape to neatly add "components" or "facilities" functionality down the line with ATSD (i.e. maybe the existing polygons will be enough and we can then edit components to contain that polygon feature ID, I'm not sure, just spitballing).
Either way, I think we can move ahead on this and then validate that assumption with Nathan/ATSD when the time comes.
Aha, I see what you're getting at. I think count-per-polygon could work for components that don't require length calculations. Maybe sidewalks, bike lanes, etc. just get mapped in their own way — or maybe they can be calculated based on the polygon to a sufficient degree of accuracy...
Anyhow, love these spitball-spurred discussions. Keep it coming! 😎
move ahead on this and then validate that assumption with Nathan/ATSD when the time comes.
Agreed. Who knows, he may come up with a facility-mapping solution himself. ;)