Issue 54 location generic geometry#151
Conversation
Signed-off-by: mperryman2 <MPerryman@geiconsultants.com>
Add conversion notes to update script
MikeNeilson
left a comment
There was a problem hiding this comment.
I have a few comments.
Going to need to come back to it later though... that was long.
| l_srid mdsys.sdo_coord_ref_sys.srid%type; | ||
| l_geometry sdo_geometry; | ||
| begin | ||
| if :new.geometry is null then |
There was a problem hiding this comment.
the column is not null, shouldn't this just fail before it gets to here?
| location_code number(14) not null, | ||
| geometry sdo_geometry not null, | ||
| geometry_type number(2), | ||
| latitude number, |
There was a problem hiding this comment.
would it be better, perhaps from a index perspective to duplicate the centroid, to another geometry object so 2nd spatial index could be used?
NOTE: I'm assuming this is duplicated/shortcutting so the lat/long rendering is easier in the view for the lat/long columsn, so maybe both, or likely just overthinking it.
| :new.longitude := l_geometry.sdo_point.x; | ||
| end if; | ||
| else | ||
| ------------------------ |
There was a problem hiding this comment.
wouldn't pulling out the centroid here still be useful to get the nearest city?
| loc.search_doc, | ||
| nvl (ll.geometry, bll.geometry) as geometry, | ||
| nvl (ll.geometry_type, bll.geometry_type) as geometry_type | ||
| from -- join the base location metadata (bas) with the location (loc) |
There was a problem hiding this comment.
| from -- join the base location metadata (bas) with the location (loc) | |
| from cwms_20.at_physical_location loc | |
| -- join the base location metadata (bas) with the location (loc) | |
| left join cwms_20.at_physical_location bas on ( bas.location_code = loc.base_location_code ) | |
| left join cwms_20.at_base_location blo on ( blo.base_location_code = loc.base_location_code ) | |
| left outer join cwms_20.at_location_geometry ll on ( ll.location_code = loc.location_code ) | |
| left outer join cwms_20.at_location_geometry bll on ( bll.location_code = loc.base_location_code) |
That was rather difficult to reason about with the joins all basically inline.
| and bp.base_parameter_id = 'Elev' | ||
| and u.unit_code = bp.unit_code; | ||
|
|
||
| select project_office_id, -- varchar2(57) the parent project's location id |
| v.nation_id, | ||
| v.nearest_city | ||
| FROM av_loc v | ||
| WHERE v.db_office_id = l_db_office_id |
There was a problem hiding this comment.
Missing sub_location_id is NULL
| AND v.db_office_id = l_db_office_id | ||
| AND v.location_code = g.location_code | ||
| AND v.unit_system = 'SI' | ||
| AND v.sub_location_id is null |
There was a problem hiding this comment.
this branch should not filter out base loc only
| p_db_office_id => p_db_office_id); | ||
|
|
||
| if not cwms_util.return_true_or_false(p_ignorenulls) or p_geometry is not null then | ||
| store_geometry( |
There was a problem hiding this comment.
if ignore nulls is true and geometry is null, this will try to store a null geometry when the column is not nullable. Use probably intends to delete the geometry in this case.
| county_name VARCHAR2 (60), | ||
| time_zone_name VARCHAR2 (28), | ||
| location_type VARCHAR2 (32), | ||
| geometry SDO_GEOMETRY, |
There was a problem hiding this comment.
move new fields to the end to avoid jOOQ codegen compatibility break or maybe overload?
| END IF; | ||
|
|
||
| ------------------------------------------ | ||
| -- get the conversion factor and offset -- |
There was a problem hiding this comment.
is the caching in cwms_util now faster than doing this join even with the pl/sql context switching?
| l_geometry | ||
| ); | ||
| end; | ||
| end if; |
There was a problem hiding this comment.
Shouldn't the else case delete the geometry if not ignoring nulls?
| loc.search_doc, | ||
| nvl (ll.geometry, bll.geometry) as geometry, | ||
| nvl (decode(ll.geometry_type, 1,'POINT', 2,'LINE', 3,'POLYGON', 4,'COLLECTION', 5,'MULTIPOINT', 6,'MULTILINE', 7,'MULTIPOLYGON'), | ||
| decode(bll.geometry_type, 1,'POINT', 2,'LINE', 3,'POLYGON', 4,'COLLECTION', 5,'MULTIPOINT', 6,'MULTILINE', 7,'MULTIPOLYGON')) as geometry_type |
There was a problem hiding this comment.
confusing that geometry_type here is text, but at_location_geometry.geometry_type is numeric. might want to swap the table to be geometry_type_code or something similar
| -------------------------------------------------------------------------------- | ||
| -- FUNCTION get_location_srid | ||
| -------------------------------------------------------------------------------- | ||
| function get_location_srid( |
There was a problem hiding this comment.
can we cache the mapping of datum to srid?
| geometry | ||
| ) | ||
| values (p_location_code, | ||
| sdo_cs.transform(p_geometry, 4326) |
There was a problem hiding this comment.
does sdo_cs short circuit if srid is already 4326?
PR Notes
Closes #54
TABLES
Addtional table AT_LOCATION_GEOMETRY
1 All GEOMETRY values are WGS 84 2-dimensional (SRID 4326).
2 These fields are populated by trigger AT_LOCATION_GEOMETRY_T01.
3 Value will be one of:
4 Values are in the datum specified in AT_PHYSICAL_LOCATION.HORIZONTAL_DATUM, if recognized. Otherwise they will be in WGS 84.
Modified table AT_PHYSICAL_LOCATION
VIEWS
AV_LOC
Added columns GEOMETRY and GEOMETRY_TYPE (from AT_LOCATION_GEOMETRY) at end. Columns LATITUDE and LONGITUDE are NULL if GEOMETRY_TYPE is NULL or != 1
AV_LOC2
Added columns GEOMETRY and GEOMETRY_TYPE (from AT_LOCATION_GEOMETRY) at end. Columns LATITUDE and LONGITUDE are NULL if GEOMETRY_TYPE is NULL or != 1
TYPES
PACKAGE SPECIFICATIONS
CWMS_LOC
Added STORE_LOCATION3 procedure which replaces the P_LATITUDE and P_LONGITUDE parameters of STORE_LOCATION2 with a single P_GEOMETRY parameter
Added RETRIEVE_LOCATION3 procedure which replaces the P_LATITUDE and P_LONGITUDE parameters of STORE_LOCATION2 with a single P_GEOMETRY parameter
Added STORE_GEOMETRY procedures
Added RETRIEVE_GEOMETRY functions
Added DELETE_GEOMETRY procedures
Added GET_LOCATION_SRID function to retrieve a location's SRID based on its hoizontal datum (returns NULL if not recognized)
Added GET_LOCATION_LAT_LON procedure, and GET_LOCATION_LAT and GET_LOCATION_LON functions to retrieve location latitude/longitude in various contexts.
PACKAGE BODIES
CWMS_CAT
CWMS_EMBANK
CWMS_LOC
CWMS_LOCK
CWMS_PROJECT
Update Script
Unlike a version update script, this one does not verify or update the CWMS schema version
The update script will transfer all LATITUDE and LONGITUDE values in the AT_PHYSICAL_LOCATION table to GEOMETRY values in the AT_LOCATION_GEOMETRY table.
If the LATITUDE or LONGITUDE value is null, the location will not have an entry in AT_LOCATION_GEOMETRY
If AT_PHYSICAL_LOCATION.HORIZONTAL_DATUM is recognized as valid, the GEOMETRY value will be properly converted to WGS 84.
If AT_PHYSICAL_LOCATION.HORIZONTAL_DATUM is NULL or not recognized, the GEOMETRY value will be created as if LATITUDE and LONGITUDE are in WGS 84.
The script stores a conversion note in AT_LATLON_CONVERSION, which can be dropped when it is no longer needed
The script outputs (via dbms_output) a summary of the conversions, similar to: