Merge locality error

[adhornsby]

Error Text

An error has occurred! May we suggest: On search pages, make sure you do not have values in fields that you do not mean to be there. Or try filling in fewer fields, the more likely to get a match. You may not have sufficient privileges to perform that operation. Consult with your supervisor or Arctos mentor.

ERROR_ID	00F09D7C-1143-4DA9-9AA7E9BA2139A89F
ERROR_TYPE	SQL
ERROR_MESSAGE	ERROR: syntax error at or near "<" Position: 645
ERROR_DETAIL
ERROR_SQL	select LOCALITY_ID, GEOG_AUTH_REC_ID, SPEC_LOCALITY, DEC_LAT, DEC_LONG, MINIMUM_ELEVATION, MAXIMUM_ELEVATION, ORIG_ELEV_UNITS, MIN_DEPTH, MAX_DEPTH, DEPTH_UNITS, MAX_ERROR_DISTANCE, MAX_ERROR_UNITS, DATUM, LOCALITY_REMARKS, GEOREFERENCE_SOURCE, GEOREFERENCE_PROTOCOL, LOCALITY_NAME, getLocalityAttributesAsJson(locality_id)::varchar localityAttrs, ST_AsText(locality_footprint) as locality_footprint, primary_spatial_data from locality where locality_id != 10937835 and GEOG_AUTH_REC_ID=1039 and 1=1 "> limit 1001

Where it happened

https://arctos.database.museum/duplicateLocality.cfm

Steps to get there

Attempting to merge 8 variations of 7385 Beryl Lane (MT: Missoula County). I get an error similar to above when the page first loads, before I change anything. When I try to search the pith (7385 Beryl) in SPEC_LOCALITY, I get a similar error regardless of whether I change the remaining fields to ignore, NULL, or leave them empty. (Trying to follow the Arctos georef video https://www.youtube.com/watch?v=YuP-hr6yvCU, merge localities starting at 29:30.) Similar errors with other localities I'm wanting to merge.

Problem

Community response to describe the problem that caused the error

Solution

Community response with directions for how to correct the problem

[Jegelewicz]

@adhornsby these merges can't happen because the localities are not the same. They either have a different elevation or coordinate error. This kind of "merging" requires someone to make changes to a locality so that it is EXACTLY the same as another. Right now I see 4 versions of 7385 Beryl Lane

LOCALITY_ID	HIGHER_GEOG	SPEC_LOCALITY	MINIMUM_ELEVATION	MAXIMUM_ELEVATION	ORIG_ELEV_UNITS	LOCALITY_REMARKS	PRIMARY_SPATIAL_DATA	DEC_LAT	DEC_LONG	MAX_ERROR_DISTANCE	MAX_ERROR_UNITS	DATUM	GEOREFERENCE_SOURCE	GEOREFERENCE_PROTOCOL
10937835	United States, Montana, Missoula County	Missoula; 7385 Beryl Lane	1038	1038	m	; VERBATIMELEVATION: 1038; VERBATIMLATITUDE: 46.819413; VERBATIMLONGITUDE: -114.10041; VERBATIMCOORDINATESYSTEM: decimal degrees	point-radius	46.81941	-114.1	100	m	World Geodetic System 1984	not recorded	not recorded
10939221	United States, Montana, Missoula County	Missoula; 7385 Beryl Lane	1039	1039	m	; VERBATIMELEVATION: 1039; VERBATIMLATITUDE: 46.819413; VERBATIMLONGITUDE: -114.10041; VERBATIMCOORDINATESYSTEM: decimal degrees; GEOREFERENCEREMARKS: Coordinates given	point-radius	46.81941	-114.1	100	m	World Geodetic System 1984	not recorded	not recorded
11859501	United States, Montana, Missoula County	7385 Beryl Lane, Missoula
11964955	United States, Montana, Missoula County	7385 Beryl Lane, Missoula		assuming 7385 Beryl Lane is the same as 7385 Beryl Drive	point-radius	46.81947	-114.1	56	m	World Geodetic System 1984	GeoLocate	GeoLocate

If you make them all exactly the same, I believe they will merge on their own over time.

[adhornsby]

@Jegelewicz I thought the point of putting "ignore" in the other fields was that the search would ignore those fields? That's what it looked like from the video (which I understand is a bit old at this point.)

I'm doing a lot of locality clean-up right now (the Beryl Lane example is one of MANY) and it's going to be really time-consuming & error prone for me to manually update every duplicate. Is that really the best way to handle all of these, or is there another option?

[dustymc]

The manual merge tool should be fixed (or removed, but this seems like good evidence that it's still useful).

[Jegelewicz]

@dustymc so it ain't working? Do I need to file an issue?

[Jegelewicz]

@dustymc can we get this working?