Geometry not written into Reviewer table

1013
5
Jump to solution
11-05-2019 02:07 PM
LavanyaSugumar
New Contributor

Hi,

   I am pretty new in using Data Reviewer. Trying to understand how all these works using ESRI's documentation provided. I am in the process of setting up a few DR validations and have few questions that need clarification.

I am using Arcmap 10.7 version. Our tables within R&H schema are normalized and were not suitable to do cross table validations through Data Reviewer. E.g. when a section of road is divided there should be a valid median type (divided_hwy and median_type being 2 different feature layers). Since we have numerous number of these cross-field validations, we went ahead and overlayed every feature layer with RH schema into one big mashup table, that could be used for any type of cross-validations. This mashup table (overlayed layers) also has geometry in it and is registered to a geodatabase. 

    I went ahead and used this mashup table in my data reviewer checks (simple SQL checks that compare divided_hwy and median_type fields). The validation executed and returned some results. However, there was no geometry written into the reviewer table and hence cannot zoom to that location from the reviewer table. I am trying to understand why the geometry is not being written. Any thoughts or suggestions?

Lavanya.

0 Kudos
1 Solution

Accepted Solutions
KumarGaurav
Esri Contributor

Hi Lavanya,

Yes, Data Reviewer creates the error geometry based on the check and then store it in the Reviewer workspace so that you can symbolize it in the map. If projection of the data and Reviewer workspace does not match then it will store that result as Row result without the geometry.

Data Reviewer also require ObjectID of the feature to Select in the map. So please register your feature class to Geodatabase, change the projection according to the Reviewer workspace and give it a try.

Hope this helps.

Thanks,

Kumar 

View solution in original post

5 Replies
KumarGaurav
Esri Contributor

Hi Lavanya,

Please make sure that the Reviewer workspace projection is similar to the data you are using.

Thanks,

Kumar

0 Kudos
LavanyaSugumar
New Contributor

Hi Kumar,

Your question made me look into the meta data and found this..

All my feature class in RH schema is projection 32123, except for my mashup table (RIMS_ROAD_INVENTORY_QA). Also I had set up my data reviewer workspace to be 32123.

I am planning to change the projection for my mashup table to be 32123 as next step. Do you think this is the cause of my issue?

Also, currently the mashup table is not registered to geodatabase, do you think it needs to be registered in order for DR to pick up the geom?

Lavanya Sugumar

Enterprise GeoSpatial Architect

ODOT Office of Technical Services

1980 W. Broad Street, Columbus, Ohio 43223

614.728.9054

transportation.ohio.gov<http://transportation.ohio.gov/>

0 Kudos
KumarGaurav
Esri Contributor

Hi Lavanya,

Yes, Data Reviewer creates the error geometry based on the check and then store it in the Reviewer workspace so that you can symbolize it in the map. If projection of the data and Reviewer workspace does not match then it will store that result as Row result without the geometry.

Data Reviewer also require ObjectID of the feature to Select in the map. So please register your feature class to Geodatabase, change the projection according to the Reviewer workspace and give it a try.

Hope this helps.

Thanks,

Kumar 

LavanyaSugumar
New Contributor

Hi Kumar,

 

  After changing the projection to 32123 on the table and also registering the table to SDE, Data Reviewer was able to detect the geometry and save the geometry in the reviewer table.

Thank you for your suggestion!

Lavanya.

0 Kudos
LavanyaSugumar
New Contributor

Hi Kumar,

 

   I have a situation with Data reviewer that I wanted to discuss and get some suggestions.

Currently, we are using Data Reviewer for Desktop and running validations on a registered feature class in Oracle and writing the output results to an FGDB.

 

Looks like Data Reviewer uses Oracle logs to process even though we write results to only an FGDB.

Our process ran yesterday and kicked out ~600 recs in error but took ~ 4hrs to complete and the Oracle log files were used at an extensive amount (occupied 60GB) that our database person had to clear the log file for the process to run.

I had asked the database person to send the snippet of the log file to understand what is going on behind the scenes.  

Trying to see how I can avoid filling up the logs… wondering if this might be the reason why it takes longer than usual to complete the validations.

 

Below are some of the sql statements that occurred during the Daily Run Data Reviewer job:

 

 

DELETE FROM SDE.SDE_logfile_data WHERE logfile_data_id = :data_id   

 

INSERT INTO SDE.SDE_logfile_data (logfile_data_id,sde_row_id) VALUES (31, :sde_row_id)

 

SELECT /*+ LEADING INDEX(SDE.SDE_logfile_data SDE.SDE_LOGFILE_DATA_IDX1) INDEX(SDE.SDE_logfile_data SDE.SDE_LOGFILE_DATA_IDX2) */ OBJECTID, ROADWAY_INVENTORY_ID, PERP_YEAR_NBR, LAST_MODIFIED_DATE, DISTRICT_NBR, NLF_ID, NLF_ID_ST, JURISDICTION_CD, COUNTY_CD, ROUTE_TYPE_CD, ROUTE_NBR, ROUTE_SUFFIX_CD, ROUTE_EXTENSION_CD, CARDINALITY_CD, CTL_BEGIN_NBR, CTL_END_NBR, SEGMENT_LENGTH_NBR, STL_BEGIN_NBR, STL_END_NBR, LEAVE_IND, REENTER_IND, GAP_LEAVE_IND, GAP_REENTER_IND, LEAVE_REENTER_TYPE_CD, PRIMARY_IND, OVERLAP_INDICATOR, COUNTY_SPLIT_INDICATOR, PRIMARY_OVERLAP_ID, SPLIT_JUR_OVERLAP_ID, OVERLAP_INVERSE_IND, SPLIT_JUR_INVERSE_IND, FUNCTION_CLASS_CD, AREA_CODE_NBR, NHS_CD, STRAHNET_CD, NHS_INTERMODAL_FACILITY_CD, DIVIDED_HWY_IND, MEDIAN_TYPE_CD, MEDIAN_WIDTH_NBR, LANES_NBR, LANE_WIDTH_NBR, SPEED_LIMIT_NBR, ACCESS_CONTROL_CD, ACCESS_CONTROL_OPNL_CD, DIRECTION_OF_TRAVEL_CD, FACILITY_TYPE_CD, FAP_IND, PRIORITY_SYSTEM_CD, SEGMENT_DESCRIPTION_TXT, MILEAGE_CLASS, ROADWAY_CLASS, STATE_CODE_LEFT, STATE_CODE_RIGHT, COUNTY_CODE_LEFT, COUNTY_CODE_RIGHT, TWP_CODE_LEFT, TWP_CODE_RIGHT, TWP_FIPS_CODE_LEFT, TWP_FIPS_CODE_RIGHT, MUNI_CODE_LEFT, MUNI_CODE_RIGHT, MUNI_FIPS_CODE_LEFT, MUNI_FIPS_CODE_RIGHT, MUNI_POPULATION_LEFT_NBR, MUNI_POPULATION_RIGHT_NBR, TAG_REVENUE_ELIGIBLE, SCENIC_BYWAY_CD, SCENIC_ROUTE_NUMBER, SHOULDER_TYPE_CD, SHOULDER_TOTAL_WIDTH_LT, SHOULDER_TOTAL_WIDTH_RT, SHOULDER_PVD_WIDTH_IN_LT, SHOULDER_PVD_WIDTH_IN_RT, SHOULDER_PVD_WIDTH_OUT_LT, SHOULDER_PVD_WIDTH_OUT_RT, STREET_PREFIX_DIR_CD, STREET_NAME, STREET_SUFFIX_CD, STREET_DIR_SUFFIX_CD, BASE_TYPE_LEFT_CD, BASE_TYPE_RIGHT_CD, SURFACE_TYPE_LEFT_CD, SURFACE_TYPE_RIGHT_CD, SURFACE_WIDTH_LEFT, SURFACE_WIDTH_RIGHT, PVMT_TYPE_LEFT_CD, PVMT_TYPE_RIGHT_CD, ROADWAY_WIDTH, TRANSACTION_REASON_CODE, TRANSACTION_COMMENT, TRUCK_ROUTE_IND, RESURFACE_YEAR, ADJ_NLF_ID, ADJ_CTL_BEGIN_NBR, ADJ_CTL_END_NBR, HPMS_SAMPLE_ID, HPMS_BEGIN_SAMPLE_DESCRIPTION, HPMS_END_SAMPLE_DESCRIPTION, HPMS_F_SYSTEM, HPMS_URBAN_CODE, HPMS_ACCESS_CONTROL, HPMS_FACILITY_TYPE, HPMS_SURFACE_TYPE, HPMS_THROUGH_LANES, HPMS_PEAK_LANES, HPMS_COUNTER_PEAK_LANES, HPMS_TURN_LANE_RIGHT, HPMS_TURN_LANE_LEFT, HPMS_PEAK_PARKING, HPMS_LANE_WIDTH, HPMS_SPEED_LIMIT, HPMS_AT_GRADE_OTHER, HPMS_STOP_SIGNS, HPMS_NUMBER_SIGNALS, HPMS_SIGNAL_TYPE, HPMS_PCT_GREEN_TIME, HPMS_SHOULDER_TYPE, HPMS_SHOULDER_WIDTH_R, HPMS_SHOULDER_WIDTH_L, HPMS_MEDIAN_TYPE, HPMS_MEDIAN_WIDTH, HPMS_PCT_PASS_SIGHT, HPMS_TERRAIN_TYPE, HPMS_WIDENING_OBSTACLE, HPMS_WIDENING_POTENTIAL, HPMS_PSR, HPMS_YEAR_LAST_IMPROVEMENT, HPMS_CURVES_A, HPMS_CURVES_B, HPMS_CURVES_C, HPMS_CURVES_D, HPMS_CURVES_E, HPMS_CURVES_F, HPMS_GRADES_A, HPMS_GRADES_B, HPMS_GRADES_C, HPMS_GRADES_D, HPMS_GRADES_E, HPMS_GRADES_F, HPMS_YEAR_REVIEWED, HPMS_DATE_CODED, HPMS_CODED_BY, HPMS_PROJECT_CODED, HPMS_REMARKS, HPMS_VOLUME_GROUP, HPMS_STD_EXP_FACTOR, SHAPE, CTL_2D_BEGIN_NBR, CTL_2D_END_NBR, SEGMENT_LENGTH_2D_NBR, STL_2D_BEGIN_NBR, STL_2D_END_NBR, SE_ANNO_CAD_DATA, 0

FROM

(SELECT DISTINCT sde_row_id

FROM SDE.SDE_logfile_data

WHERE SDE.SDE_logfile_data.logfile_data_id = :lf_data_id ) LF_, RIMS_QA.RIMS_ROAD_INVENTORY_QA

WHERE (substr(NLF_ID, 14, 1) = 'C' AND substr(NLF_ID, 13, 1) <> 'P' AND ((ROADWAY_CLASS = 3 AND SURFACE_TYPE_RIGHT_CD <> 'X') OR (ROADWAY_CLASS <> 3 AND SURFACE_TYPE_RIGHT_CD = 'X'))) AND (LF_.sde_row_id = RIMS_QA.RIMS_ROAD_INVENTORY_QA.OBJECTID)

 

 

The delete statement was executed more than the other two sql commands.

0 Kudos