fix: schemas/util.sql: contained_within_approx(geocoord, postgis.geometry): renamed to contained_within__no_dateline(__) because this is not an approximate comparison for geometry
schemas/util.sql: lat_long_in_new_world(): renamed to just in_new_world() because the lat/long is implied by the param type
schemas/util.sql: lat_long_in_new_world(): take a geocoord param instead of separate lat/long params
backups/TNRS.backup.md5: updated
schemas/util.sql: added contained_within_approx(geocoord, geometry) and corresponding OPERATOR ~@(geocoord, geometry)
schemas/util.sql: added OPERATOR ~@(geocoord, geography)
schemas/util.sql: lat_long_in_new_world(): use new contained_within_approx(geocoord, geography)
schemas/util.sql: added contained_within_approx(geocoord, postgis.geography), which enables specifying just `(lat, long)` without the ::util.geocoord type specifier
schemas/util.sql: OPERATOR (postgis.geography, postgis.geography): renamed to ~ because it's approximate
(postgis.geography, postgis.geography): renamed to ~
schemas/util.sql: contained_within(): renamed to contained_within_approx() because the latitude lines of geography type bounding boxes bulge outward, creating false positives above and below the bounding box
schemas/util.sql: added contained_within__no_dateline(geometry, geometry) and corresponding operator @
schemas/util.sql: geometry(geocoord): documented that it is not possible to create a cast for this, as a bug in pg_dump prevents the cast from being exported, even when no export filters are applied
schemas/util.sql: point(geocoord): renamed to geometry(geocoord) since this is now a cast
schemas/util.sql: point(): return geometry instead of geography to support using points with geometry arithmetic
schemas/util.sql: point(): take a single util.geocoord param instead of separate lat/long
schemas/util.sql: added geocoord type
schemas/public_.sql: 2014-6-4.Iara_Lacher.reserve_prioritization: include only georeferenced occurrences (lat/long NOT NULL)
schemas/util.sql: bounding_box(): use bounding_box__no_dateline() to construct the postgis.geometry object
schemas/util.sql: added bounding_box__no_dateline(), which is more accurate than util.bounding_box() (latitude lines will be straight), but geocoordinate wraparound is not supported
schemas/public_.sql: 2014-6-4.Iara_Lacher.reserve_prioritization: added functional traits that we have 1st-class columns for (dbh_cm, height_m)
added exports/2014-6-4.Iara_Lacher.reserve_prioritization.csv.run
inputs/publishable datasources.xlsx: updated
inputs/.TNRS/schema.sql: matchedFamily: just use Name_matched_accepted_family, because TNRS has now been reloaded so that the names that were missing this have it populated
planning/meetings/BIEN conference call availability.xlsx: updated
inputs/.TNRS/schema.sql: taxon_match: taxon_match__valid_match: replaced with taxon_best_match__valid_match, which also applies taxon_best_match's filters, since taxon_match is now accessed through taxon_best_match
fix: inputs/.TNRS/schema.sql: MatchedTaxon: use taxon_best_match instead of taxon_match because this should provide only one match per taxon
bugfix: /README.TXT: Mac settings backup: backup to jupiter: need to exclude ~/software/**/.svn/ because these are different on jupiter
/README.TXT: Mac settings backup: backup to jupiter: removed no longer applicable exclude of /VirtualBox VMs/Ubuntu/Ubuntu.vdi
inputs/.TNRS/schema.sql: added taxon_best_match view
inputs/.TNRS/schema.sql: taxon_match: added taxon_match__one_selected_match unique index
inputs/.TNRS/schema.sql: taxon_match__fill(): split into separate DECLARE blocks for each field for clarity
inputs/.TNRS/data.sql: refreshed
fix: inputs/.TNRS/schema.sql: taxon_match: renamed related items to start with taxon_match__*
inputs/.TNRS/schema.sql: taxon_match: insert names via taxon_match_input auto-updatable view instead of directly into taxon_match, to allow the taxon_match columns to be renamed while still supporting inserts using the TNRS column names
fix: schemas/Makefile: vegbien.sql: also need to update inputs/.TNRS/data.sql, since its contents change along with this
inputs/.TNRS/schema.sql: tnrs_match: renamed to taxon_match to use the normalized VegCore name for this, and to avoid repeating the schema name
lib/tnrs.py: dirty: documented that this actually used to be on in the web app (see r9910, 2013-6-18), but does not appear to be needed (the source_sorting bug alluded to in r9910 is not fixed by enabling the dirty setting)
lib/tnrs.py: requests: also debug-print request URL
lib/tnrs.py: Download: include the same debug info as do_request()
lib/tnrs.py: do_request(): also debug-print request headers
lib/tnrs.py: download_request_template: dirty: documented why this must be off
bugfix: lib/tnrs.py: download_request_template: fixed bug where multiple names were being marked as Selected, because dirty was incorrectly set to true unlike in the web app
added derived/TNRS/web_app/protocol/
bugfix: inputs/.TNRS/schema.sql: taxon_name_is_safe(): need to use `NOT (_ = ANY()) instead of ` != ANY`, because the != operator is applied to each element
inputs/.TNRS/schema.sql: tnrs: renamed to tnrs_match to distinguish it from other TNRS-related tables
fix: lib/phpPgAdmin.login.php.diff: use relative file path rather than the path the file was at when the patch was created
/Makefile, lib/phpPgAdmin.login.php.diff: public_ user: added auto-filled password so that users would not be confused as to what to type in the password field
added schemas/VegCore/phpMyAdmin/libraries/plugins/auth/AuthenticationCookie.class.php.diff
inputs/.TNRS/schema.sql: `taxon_scrub.scrubbed_unique_taxon_name.*`: added to-modify instructions
inputs/.TNRS/schema.sql: *_modify(): merged these into the "to modify" instructions in the corresponding views, because there is no need to create a separate *_modify() function for every view now that their definitions are all the same
validation/aggregating/plots/bien3_validations_salvias_vegbien.sql: updated to DB
schemas/public_.sql: analytical_stem_view and related views: updated COMMENTs from data dictionary spreadsheet, using the steps at wiki.vegpath.org/VegBIEN_schema_refactoring#copy-data-dictionary-definitions-to-database
schemas/public_.sql: ran analytical_stem_view_modify(), which transfers the column COMMENTs from analytical_stem_view to analytical_stem
bugfix: schemas/util.sql: view_def_to_orig(): need to handle cases when list of cols from the same table is not an expanded * expression
schemas/util.sql: added view_is_subset(view_def text)
schemas/util.sql: added view_is_automatically_updatable(view_def text)
bugfix: schemas/util.sql: show_create_view(): use the overridden version of pg_get_viewdef(), which supports expanded * expressions. this was possibly being used already whenever util happened to be in the search_path.
bugfix: schemas/public_.sql: analytical_stem_view_modify(): updated to new analytical_stem_view column names
fix: schemas/public_.sql: analytical_stem_view derived and related views: applied data dictionary renamings, using the steps at wiki.vegpath.org/VegBIEN_schema_refactoring#apply-data-dictionary-renamings-to-database but with the current columns of analytical_stem as the left-hand column
schemas/public_.sql: analytical_stem_view: applied data dictionary renamings, using the steps at wiki.vegpath.org/VegBIEN_schema_refactoring#apply-data-dictionary-renamings-to-database
lib/tnrs.py: source_sorting (Constrain by Source): documented the different behavior for this in each match mode (all-matches and best-match)
schemas/public_.sql: added 2014-6-4.Iara_Lacher.reserve_prioritization
bugfix: web/.phpPgAdmin/.htaccess: : handlers: use `chain` to only run them when the RewriteRule they apply to is run
web/.phpPgAdmin/.htaccess: schema : handler: removed `env=subject:schema` because that has already been set
web/.phpPgAdmin/.htaccess: tables: added : suffix handler
bugfix: web/.phpPgAdmin/.htaccess: view : match: moved to right after `view=` because it only applies to views, not functions
web/.phpPgAdmin/.htaccess: schema: page: indicate by prefixing with : to avoid needing to explicitly list all possible pages
web/.phpPgAdmin/.htaccess: table: action: indicate by prefixing with : to avoid needing to explicitly list all possible actions
exports/2014-6-12.Jeff_Ott.climatic_range_determinants.csv.run: updated export_() runtime (35 min) and rowcount (23 million)
fix: /README.TXT: Full database import: disk space: removed instructions to rerun the import if the disk space gets used up, because this is actually a bug and is not generally "fixed just by rerunning the import"
schemas/util.sql: lat_long_in_new_world(): use function rather than operator+search_path to allow inlining, which enables util.new_world() to only be evaluated once
bugfix: schemas/util.sql: operator @(postgis.geography, postgis.geography): must use wrapper function because st_coveredby() needs postgis to be in the search_path
fix: lib/runscripts/extract.run: export_(): explicitly prevent files from becoming web-accessible, to protect against an incorrect umask in the calling process
fix: schemas/util.sql: point(): hide benign "Coordinate values were coerced into range [-180 -90, 180 90] for GEOGRAPHY" notices
schemas/public_.sql: 2014-6-12.Jeff_Ott.climatic_range_determinants: also include New World occurrences by coordinates, using new lat_long_in_new_world(). this modification (as requested by Jeff) will help reduce the false negatives filtered out by including only data with placenames.
schemas/public_.sql: added lat_long_in_new_world() wrapper around util.lat_long_in_new_world()
schemas/util.sql: lat_long_in_new_world(): documented that this includes false positives above and below the New World bounding box, as described in util.bounding_box()
schemas/util.sql: bounding_box(): documented that the geography type stores all edges as arcs of great circles, resulting in the latitude lines bulging outward from the true bounding box. this will create false positives above and below the bounding box.
schemas/util.sql: added lat_long_in_new_world()
schemas/util.sql: added operator @(postgis.geography, postgis.geography). can't use && for this because it only compares 2D bounding boxes (which are geometry objects that do not support geocoordinate wraparound).
schemas/util.sql: added point()
schemas/util.sql: new_world(): removed no longer needed cast to postgis.geography
bugfix: schemas/util.sql: bounding_box(): must use postgis.geography (instead of postgis.geometry) because that handles geocoordinate wraparound correctly
bugfix: schemas/util.sql: bounding_box(): need to explicitly set SRID to make sure the correct value is used
bugfix: schemas/util.sql: bounding_box(): use st_makeenvelope() instead of st_makebox2d() because st_makebox2d() doesn't support geocoordinate wraparound (it is not SRID-aware)
schemas/util.sql: new_world(): removed no longer needed cast to postgis.geometry
schemas/util.sql: bounding_box(): return postgis.geometry instead of postgis.box2d because box2d is not directly used in postgis functions
bugfix: /Makefile: mk_db: plpython3u: use CREATE EXTENSION instead of createlang so that the plpython3u extension is created in addition to the plpython3u language (as it is on Linux)
