Geometry role and concept hierachy
Closed this issue · 7 comments
Vance,
Proposed simplification.
Change 'role' to 'type' to be more specific.
Regarding hierarchy, remove 'Boundary'. 'Centroid' and 'Detailed geometry' should suffice.
Change 'centroid' to 'point'.
Change 'detailed geometry' to 'other vector shapes'.
Justification
The current geometry grid allows for one set of coordinates which covers the 'centroid' concept. However, polylines and polygons (all the complex shapes included in 'boundary') would require a large number of points to be entered manually. No one will do that. Not to mention that at this stage you can choose a 'hull' but all you can enter is ONE set of coordinates. It looks weird for lack of a better word. Polylines and polygons belong to 'Detailed geometry' or more generically 'other vector shapes'.
This change would also allow for an improvement I suggested for Geoprop, to make the upload of a zipped shape file 'mandatory' when the user chooses 'detailed geometry' or 'other vector shapes'. In this way, geometry makes sense. The user may enter manually a point for a field sample, borehole, site observation, etc but is required to provide a shape file for any other vector data.
@DavidCrosswellGSQ See comments from @predam1.
It echoes some of the concerns we have raised around boundary as a concept. amongst other things).
A few things here:
-Geometry types has a special meaning inPostGIS Eg: 'LINESTRING', 'POLYGON', 'MULTIPOINT', etc
-Geometry roles also have a special meaning, which is distinct from type. For example:
---A single xy point (type= point) could have role= detailed geometry if type= point.
---A single xy point (type= point) cannot have role= detailed geometry if it is just a point representation of an area. Here role= centroid might be appropriate because the true role= detailed geometry would have type=polygon.
---Similarly, a single xy point (type= point) cannot have a role= bounding box. Here, type= polygon might be appropriate.
---In all of these cases, we will need to rely on staff education, rather than data validation, to ensure data integrity.
In reference to the suggested changes to the vocab I think we need to first focus on building understanding in PostGIS and the new systems.
From there we would be better placed to address the root causes of the issues within Geoprops.
Our testers that found geometries and roles difficult to work with would be ideal to review the user manual I am starting to put together, and I am happy to deliver an education session on this one too.
Ok, I understand the 'type' issue. What is the definition of 'role'?
In relation to the other terms - what I'm suggesting is to use simple self-explanatory terms, which require limited instruction.
In terms of a manual, Tony Niewenburg is compiling guidelines for the lodgement of geological spatial data. I think SGS is in a better position to do develop such spatial guidelines. Apparently, it's going to be a link in the lodgement portal to take the user to a page with instructions. Geoprops could do the same.
The geometry types come from the OGC standard http://portal.opengeospatial.org/files/?artifact_id=25354
The original rationale was that our systems could handle the customer providing multiple geometries to us and us being able to store those multiple geometries. By tagging each geometry with a role, we could know what purpose the geometry served. e.g. for a mine site - we could have a centroid of mine, a concave hull of the extents of the mine site, and a detailed geometry that showed the precise geometry (e.g. a multi-part polygon).
For a seismic survey, we could have a detailed geometry (the seismic lines as a multi-line) and the survey area coverage (e.g. a concave hull).
Probably hasn't resolved the question, but may add to the rationale.
Thanks for the document David. I've looked through and I couldn't find 'role', only 'type' in relation to all the types of vector data. 'Role' is a function not an attribute so it isn't suitable for use in defining spatial data.
Furthermore, 'role' doesn't exist in the ESRI-supported GIS dictionary or the ArcGIS Help. Google searches produced 2 results: our VocPrez! and the mathematical association (as in the role of geometry).
Just a reminder that my suggestion was not only about using the mainstream names (that users can get without a manual) but also about what's practical to input under Geometry in the Geoprop grids. Point coordinates can be easily entered, all the other shapes require too many points to define and, in those cases, shapefiles should be mandatory.
In relation to your diagram Derek, most of the features on that mud map are vector objects and can be spatially represented by shapefiles, although I don't consider gates, fences or roads relevant to the Geoprop portal. For pits and dumps, we need raster format files, which we cannot enter in any of the portals at this stage.
I rest my case.
Closed this stale issue as the case has long been rested.
If still a concern, it should be raised through the Product Managers forum as commentary about the UI/UX but it doesn't belong here because there is no issue with the geometry role vocabulary.