Location name suggestions

Improves observation form's handling of locations.

Officially changes policy concerning including counties back to what it was at the beginning: counties are now encouraged again.

When lat/long is updated (pin dropped or dragged, gps taken from image header, user enters it by hand), it uses google to reverse geolocate, and it sends the resulting info to the observer controller: country, state, county, city.  (It makes the submit buttons wait for google to respond.)

"Earth" is no longer considered acceptable.  It will complain "please enter at least country!" and force the user to approve "Earth" before accepting it.  If geolocation data is available, it will suggest existing locations which contain the lat/long, or which match google's reverse geolocation, or if nothing matches it will suggest a fairly reasonable name for a new location based on google's reverse geolocation.  This latter will require some editing in some cases, but it will at least be better than nothing.

If the lat/long is way outside of the bounding box for the chosen location, it will complain, and it will suggest some alternative existing locations which contain the lat/long.

If a smaller location contains the lat/long it will suggest this location.

If the location name entered does not match an existing location, it will go to some rather extreme efforts to correct a number of common mistakes, including but not limited to correcting spelling mistakes, filling in omitted country, state, county, unabbreviating states.  It will use info from google's reverse geolocation in some cases to fill in missing terms.  But importantly, this process will only ever suggest existing locations.  All the usual mistakes are still going to happen when creating new locations.

If any of the above cause MO to suggest one or more alternative location names, it will reload the form and display the suggestions as a set of radio boxes, along with at least some explanation of why we're suggesting the alternative locations.  The user can then click any of the radio boxes and re-submit.  Or the user can simply resubmit the form to "approve" whatever data they already have entered.

All tests are passing, but I feel like a good deal more testing is required before merging this.  Also, two of the primary location name correction methods (in app/models/location/suggestions.rb) violate ABC complexity and should probably be refactored a bit.  I will take a look at this later when I'm fresher to see if any clever ideas arise.
Meanwhile, this is a working draft.

Wow! This sounds great!
Thanks so much.
But I won't have a chance for a detailed look until this evening
or tomorrow morning.
On Wed, Dec 2, 2020 at 12:18 AM Jason Hollinger<EMAIL_ADDRESS>wrote:

Improves observation form's handling of locations.

Officially changes policy concerning including counties back to what
it was at the beginning: counties are now encouraged again.
2.
When lat/long is updated (pin dropped or dragged, gps taken from image
header, user enters it by hand), it uses google to reverse geolocate, and
it sends the resulting info to the observer controller: country, state,
county, city. (It makes the submit buttons wait for google to respond.)
3.
"Earth" is no longer considered acceptable. It will complain "please
enter at least country!" and force the user to approve "Earth" before
accepting it. If geolocation data is available, it will suggest existing
locations which contain the lat/long, or which match google's reverse
geolocation, or if nothing matches it will suggest a fairly reasonable name
for a new location based on google's reverse geolocation. This latter will
require some editing in some cases, but it will at least be better than
nothing.
4.
If the lat/long is way outside of the bounding box for the chosen
location, it will complain, and it will suggest some alternative existing
locations which contain the lat/long.
5.
If a smaller location contains the lat/long it will suggest this
location.
6.
If the location name entered does not match an existing location, it
will go to some rather extreme efforts to correct a number of common
mistakes, including but not limited to correcting spelling mistakes,
filling in omitted country, state, county, unabbreviating states. It will
use info from google's reverse geolocation in some cases to fill in missing
terms. But importantly, this process will only ever suggest existing
locations. All the usual mistakes are still going to happen when creating
new locations.
7.
If any of the above cause MO to suggest one or more alternative
location names, it will reload the form and display the suggestions as a
set of radio boxes, along with at least some explanation of why we're
suggesting the alternative locations. The user can then click any of the
radio boxes and re-submit. Or the user can simply resubmit the form to
"approve" whatever data they already have entered.
All tests are passing, but I feel like a good deal more testing is
required before merging this. Also, two of the primary location name
correction methods (in app/models/location/suggestions.rb) violate ABC
complexity and should probably be refactored a bit. I will take a look at
this later when I'm fresher to see if any clever ideas arise.
Meanwhile, this is a working draft.
You can view, comment on, or merge this pull request online at:
https://github.com/MushroomObserver/mushroom-observer/pull/718
Commit Summary

Replaced homespun levenshtein distance with gem version (written in
C).
Added Location.suggestions to suggest similar existing location
names when a location name is not recognized.
On second thought, Location.suggestions should ignore user name
format preference to be more in line with other Location class methods.
Have observation form suggest similar location names if given
location doesn't exist.
Removed "redundant county" warning, since our users have clearly
chosen to ignore it wholesale.
Fixed some simple bugs.
Merge branch 'master' of github.com:MushroomObserver/mushroom-observer
into location-name-suggestions
Major overhaul of location suggestions. Should cover a lot more of
the common mistakes now.
Have map on obs form reverse geocode address for lat/long if user
drops a pin on the map, and it sends this with the rest of the form data.
Have observation form submit buttons wait up to 10 seconds for
geocoder to return.
Added state abbreviations file (just includes Canada, Mexico and USA
for now).
Got reverse geocoder to work in observation form.
Made GM::GMaps.key accessible to everyone, including javascript erb
templates.
Fixed some typos.
Added a location to fixtures that's in a country other than USA or
Canada.
Added a whole bunch of tests for location suggestions stuff.

Apparently the bare word "ON" means "true" in YAML.
Added "location_suggestion_reasons".
Updated list of public methods in comments, and added center,
pseudoarea, and close?.
Got location suggestions working.
Got location suggestions working.
No need for args in GMap.header.
Need to parse lat and long before using it for geolocation.
Got observer_controller tests to pass again.
Changed text of the location help policy concerning inclusion of
county in location names.
Changed east > west to east >= west so that east = west is treated
as normal instead of straddling dateline.
Forgot to name two tests.
Tweaked this test to account for new location suggestions.
Rubocopping new location suggestions stuff.

File Changes

M Gemfile
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-d09ea66f8227784ff4393d88a19836f321c915ae10031d16c93d67e6283ab55f
(3)
M Gemfile.lock
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-89cade48462044ee1b672dc5f4c3ec250fbd29effcd8932096a23c1283c6731f
(2)
M app/assets/javascripts/observation_form_map.js.erb
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-0b9a6cc77aef1d027220fa5ec9c94c8cc8f57b59b5a721cf0ce1809c3737f968
(76)
M app/classes/geocoder.rb
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-689c423f1dbd569c480342f6065fbdbe47015632c271a86a6afe6a5c71e87bc5
(9)
M app/classes/gmaps.rb
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-5d2f3f1e374dd0031b0d8ed8faffd819105327edbdb0eff8581948e190499f3c
(12)
M
app/controllers/observer_controller/create_and_edit_observation.rb
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-09b44a03acc8b7f44efc472a7ef1ee3d2a121de6091862c9be15eb75815e513d
(134)
M app/extensions/string_extensions.rb
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-c792dcce221c3fd9a83af351b5d89ff67c479daf23413d2febab838bbda3b549
(41)
M app/helpers/map_helper.rb
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-8d74af7263c776dfd4058163ec3c3e6baa30db38756a0064d689bab6a65c77e9
(2)
M app/models/location.rb
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-83acc4923e9ebe15ae1c7ed932799fabc336c772c0e9233e1537a435da8cb1dc
(80)
A app/models/location/suggestions.rb
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-672adecdebacdac4987794ea3de2478551a082f6272412782d00d16ea6643c1a
(212)
M app/views/observer/_form_observations.html.erb
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-df3428c548cdca2b682ef5a4f186601eeb10abbd5680ff974499e25f77d85966
(28)
M config/consts.rb
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-8df7a9c893259da19d023b287763b71a11be30518b71d6c927114168e27e6748
(11)
M config/locales/en.txt
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-6c8f8f09f3fa9ec6ef439f25ecefa7532a0adf9b76a06d1595aa64e049b979e0
(8)
A config/location/state_abbrs.yml
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-d671595794d6659d9af175a2be46c5421c157ddbb68f7ad611b1b26e6468c04b
(112)
M test/controllers/observer_controller_test.rb
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-1f21ebcbd530f50a48f065f398b8a9d3e5f8c31a7c62ea8062fd62c631ec5e9e
(487)
M test/fixtures/locations.yml
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-3cf1db5a137a3762aa3fc897b59f4927f227d87eb9f9dd07c9ac935606a8038c
(11)
M test/integration/post_observation_test.rb
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-084f30a27208cc83792b14f314be90b2b65a5903516ea7ffba1436f626c9f6d0
(16)
M test/models/location_test.rb
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-54d1817af5bd3bf5e2dc418d40fc5e5896518c4c02076cd86f318f509cb34fca
(2)
M test/models/string_extensions_test.rb
https://github.com/MushroomObserver/mushroom-observer/pull/718/files#diff-67b04bbf0346bfd8a84c3db83a9fd3cf555783b9d61ad6019e09493879bdab29
(18)

Patch Links:

https://github.com/MushroomObserver/mushroom-observer/pull/718.patch
https://github.com/MushroomObserver/mushroom-observer/pull/718.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAALDFHAE76HLZN3OYAJUDLSSXZ5ZANCNFSM4UKEMVWA
.

This will be super in practice: better exports, less work for admins, more consistency.
But I'd like to understand if it would likely to cause out-of-pocket expenses for MO, Inc. I think we'll be okay, but I'd like to double check.
What's your best guess how many geocode requests/mo would be added by this PR?
(Back of the envelope numbers: we could do 20,000 additional GeoCode requests/month without incurring out-of-pocket costs.)
Background:

We get $450/mo free use of GoogleMaps ($200 free tier, plus annually, manually renewed $250 nonprofit credit).
For the last 12 months we've averaged ~$210/mo. Of course, there are months where we go higher. In October 2020, we hit $293.45. So we have about $150 to spare without incurring out-of-pocket expenses. Both the average and max monthly costs are likely to increase.

Geocoding costs 0.005 USD per each request (if one makes 0–100,000 requests/month). https://developers.google.com/maps/documentation/geocoding/usage-and-billing
At that rate we can do 30,000 requests in a month like Oct 2020. With a safety margin of 10K requests/month, we could do 20,000 requests/month.

Suggested locations will give some screwy-looking answers because the boundaries of many current locations are screwed up. For instance: with Where field empty, attached photo, and accepting lat/lon (38.8495/-123.6387) from photo, suggested places are

Please enter at least the country! Here are some existing locations. Will one of these work? If you submit the form again without any changes we will accept your observation as-is.

Mono Creek Overflow, Sierra NF, Fresno Co, California, USA
Santa Rosa Memorial Park Cemetery, Santa Rosa, California, USA
Odd Fellows Cemetery, Santa Rosa, California, USA
Chesterfield Post Office, Chesterfield, Missouri, USA
Robert J. Henke Nature Preserve, Lake Grove, New York, USA
Iversen Dr., south of Point Arenas, Mendocino Co., California, USA
Meeting of the Pines Natural Area, Michaux State Forest, Pennsylvania, USA

Two ideas:

Exclude from suggested locations anything in a different country, state, or county than that obtained by a reverse geocode of the photo coordinates. (Here, that would have left Iversen Drive, which is perfect.)
Exclude anything with an area that's "too large". (It would be interesting to know how many Locations are too large.)

I haven't dug into the code, but I assume you are deliberately not suggesting Locations which have parts of the Location name missing, e.g., in the above case: "California, USA" and "Mendocino Co., California, USA". What do you think about including counties in the suggestions?

This will be super in practice: better exports, less work for admins, more consistency.
But I'd like to understand if it would likely to cause out-of-pocket expenses for MO, Inc. I think we'll be okay, but I'd like to double check.
What's your best guess how many geocode requests/mo would be added by this PR?
(Back of the envelope numbers: we could do 20,000 additional GeoCode requests/month without incurring out-of-pocket costs.)
Background:

We get $450/mo free use of GoogleMaps ($200 free tier, plus annually, manually renewed $250 nonprofit credit).
For the last 12 months we've averaged ~$210/mo. Of course, there are months where we go higher. In October 2020, we hit $293.45. So we have about $150 to spare without incurring out-of-pocket expenses. Both the average and max monthly costs are likely to increase.

Geocoding costs 0.005 USD per each request (if one makes 0–100,000 requests/month). https://developers.google.com/maps/documentation/geocoding/usage-and-billing
At that rate we can do 30,000 requests in a month like Oct 2020. With a safety margin of 10K requests/month, we could do 20,000 requests/month.

PS: Some numbers to think about.
Observations created 2020 YTD: 42,695 (including deleted Observations). So if geocode were called for each one, we'd pay ~$145 out of pocket.
Locations created or updated 2020 YTD: 2,809. Probably a better count would be # of LocationVersions updated_at like 2020%.

Excellent questions, Joe.
re: numbers -- Is there a typo?  You said we get 20,000 requests per month,
and we created 40,000 observation this year, so that would be 3333
observations per month, allowing up to 6 geocoding requests per
observation.  There are ways to mitigate it, as well.  For example, do the
reverse geocode request only when the form is submitted, reducing it to 1
per observation, and only for obs with lat/long.  Maybe further restricting
it to obs that don't already have a valid location containing the lat/long.
re: bogus location suggestions -- Yikes.  That is a mess.  I like your idea
of leveraging reverse geocode info better where it is available.  (And it
should always be available in cases like the one you mention.)
re: not including California, Earth -- Yes, it is only suggesting the most
"accurate" locations which contain the given lat/long.  Accuracy measured
very roughly by the number of "terms" in the location name.  Therefore if
"Burbank, Los Angeles Co., California, USA" contains the point, then only
locations with 4 terms will be suggested.  If there is a 5-term location
containing that point, then Burbank won't even be suggested, either.  It
also only suggests existing locations.  And since most counties are not
actually defined locations (towns within a county may exist, but the county
itself doesn't have an existing location all to itself), that means most
counties won't even be considered.  It started to get prohibitively
confusing when I started trying to simultaneously autocorrect location
names and suggest existing location names.  Since the primary goal was to
save poor Igor (and me!) the trouble of repeatedly cleaning up bad versions
of existing locations, I focused on that aspect.  (The one exception is if
it can't suggest any existing location and no location is written in at
all.  Then it will suggest a non-existing location name for you based on
google reverse geocode info.)
Thanks for taking it for a test drive!  I hadn't actually taken the time to
run it live (on the dev VM) yet myself.  I didn't realize how far short of
my optimistic expectations it fell! :)
Both this PR and my other are likely to fester a bit, because I promised to
devote December to catching up on "professional" lichen work.  But I will
try to merge master into both periodically to make sure they don't go
stale, at least, because I am still very interested in both.
On Thu, Dec 3, 2020 at 10:41 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

This will be super in practice: better exports, less work for admins, more
consistency.
But I'd like to understand if it would likely to cause out-of-pocket
expenses for MO, Inc. I think we'll be okay, but I'd like to double check.
What's your best guess how many geocode requests/mo would be added by
this PR?
(Back of the envelope numbers: we could do 20,000 additional GeoCode
requests/month without incurring out-of-pocket costs.)
Background:

We get $450/mo free use of GoogleMaps ($200 free tier, plus
annually, manually renewed $250 nonprofit credit).
For the last 12 months we've averaged ~$210/mo. Of course, there are
months where we go higher. In October 2020, we hit $293.45. So we have
about $150 to spare without incurring out-of-pocket expenses. Both the
average and max monthly costs are likely to increase.

Geocoding costs 0.005 USD per each request (if one makes 0–100,000
requests/month).
https://developers.google.com/maps/documentation/geocoding/usage-and-billing
At that rate we can do 30,000 requests in a month like Oct 2020. With a
safety margin of 10K requests/month, we could do 20,000 requests/month.
PS: Some numbers to think about.
Observations created 2020 YTD: 42,695 (including deleted Observations). So
if geocode were called for each one, we'd pay ~$145 out of pocket.
Locations created or updated 2020 YTD: 2,809. Probably a better count
would be # of LocationVersions updated_at like 2020%.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-738546037,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNPEIHWRZJDWUQHUDZLSTBLAJANCNFSM4UKEMVWA
.

The numbers look OK to me, so it looks like the PR won't cause financial problems.
Those are great ideas if we run into problems in the future. Another thing to keep in mind is to stop using the GoogleMaps Elevation API, which accounts for about 20% of our costs.

Excellent questions, Joe. re: numbers -- Is there a typo? You said we get 20,000 requests per month, and we created 40,000 observation this year, so that would be 3333 observations per month, allowing up to 6 geocoding requests per observation. There are ways to mitigate it, as well. For example, do the reverse geocode request only when the form is submitted, reducing it to 1 per observation, and only for obs with lat/long. Maybe further restricting it to obs that don't already have a valid location containing the lat/long.

Yes, good idea re: elevation api.  Hey, how about this?  Instead of doing
it on the form, do it on the server after the obs is created, and obviously
only if elevation is not already given.  Normally we don't do it that way
because we don't want to tie up a server thread waiting for google api to
return, but in that case we can just launch a background job to do it.
On Fri, Dec 4, 2020 at 3:26 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

The numbers look OK to me, so it looks like the PR won't cause
financial problems.
Those are great ideas if we run into problems in the future. Another
thing to keep in mind is to stop using the GoogleMaps Elevation API, which
accounts for about 20% of our costs.

Excellent questions, Joe. re: numbers -- Is there a typo? You said we get
20,000 requests per month, and we created 40,000 observation this year, so
that would be 3333 observations per month, allowing up to 6 geocoding
requests per observation. There are ways to mitigate it, as well. For
example, do the reverse geocode request only when the form is submitted,
reducing it to 1 per observation, and only for obs with lat/long. Maybe
further restricting it to obs that don't already have a valid location
containing the lat/long.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-739001203,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNMX5WLDCYXH3YHRKLDSTFAXFANCNFSM4UKEMVWA
.

Re elevation API, form vs server. Seems complicated and easy to lose track of. I'd forget about it for now given that we currently seem to have Google API requests to spare.

Yes, good idea re: elevation api. Hey, how about this? Instead of doing it on the form, do it on the server after the obs is created, and obviously only if elevation is not already given. Normally we don't do it that way because we don't want to tie up a server thread waiting for google api to return, but in that case we can just launch a background job to do it.
…
On Fri, Dec 4, 2020 at 3:26 PM Joseph D. Cohen @.***> wrote: - The numbers look OK to me, so it looks like the PR won't cause financial problems. - Those are great ideas if we run into problems in the future. Another thing to keep in mind is to stop using the GoogleMaps Elevation API, which accounts for about 20% of our costs. Excellent questions, Joe. re: numbers -- Is there a typo? You said we get 20,000 requests per month, and we created 40,000 observation this year, so that would be 3333 observations per month, allowing up to 6 geocoding requests per observation. There are ways to mitigate it, as well. For example, do the reverse geocode request only when the form is submitted, reducing it to 1 per observation, and only for obs with lat/long. Maybe further restricting it to obs that don't already have a valid location containing the lat/long. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#718 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYTNNMX5WLDCYXH3YHRKLDSTFAXFANCNFSM4UKEMVWA .

Codeclimate/Brakeman issues.
Potentially unsafe model attribute in link_to href NEW

31 link_to(link_string, location.show_link_args)
Severity: MinorFound in app/helpers/object_link_helper.rb by brakeman

brakeman (latest version) does complain when run locally. This is a XSS issue. See https://brakemanscanner.org/docs/warning_types/link_to_href/. The local brakeman report has an expanded version of the possibly unsafe line:

Potentially unsafe model attribute in link_to href near line 32:

link_to((where_string(Location.find(location).display_name, count) + " [#{:click_for_map.t}]"), Location.find(location).show_link_args)

Possible SQL injection NEW

223 WHERE id IN (#{locations.keys.sort.map(&:to_s).join(",")})
Severity: MinorFound in app/controllers/observer_controller/indexes.rb by brakeman

Local report (with line expanded):
SQL Injection | Possible SQL injection near line 223:
Location.connection.select_rows(
 SELECT id, name, north, south, east, west FROM locations
 WHERE id IN (#{{ loc_id.to_i => nil }.keys.sort.map(&:to_s).join(",")})
)

Grr. I broke this. I will try to fix it tonite or more probably tomorrow.

This branch works through #ac591e983d03b45bcd948ad77567fd5918873010
It breaks with #a401a3aa172322a878b17e7a2fb151f118d5c99f

With #b97d0b5, CreateAndEditObservation is covered 100%.
So I will now poke at location suggestions (maybe starting tomorrow).

Maybe it isn't supposed to fail without somehow raising an error or
something like that.  So if you just stub it and have it return false, no
error message is actually produced?
On Thu, Dec 24, 2020 at 6:47 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

@JoeCohen commented on this pull request.
In test/controllers/observer_controller_test.rb
https://github.com/MushroomObserver/mushroom-observer/pull/718#discussion_r548763428
:

params = {

 id: obs.id.to_s,

 observation: {

   notes: { other: "new notes" },

   place_name: obs.where,

   "when(1i)" => "2006",

   "when(2i)" => "05",

   "when(3i)" => "11",

   specimen: obs.specimen,

   thumb_image_id: obs.thumb_image_id

 },

 log_change: { checked: "0" }

}

login(obs.user.name)
Observation.any_instance.stubs(:save).returns(false)

Same questions about stubbing
The point is to cover line 452:
446           if save_observation(@observation)
...451           else452             any_errors = true

In test/controllers/observer_controller_test.rb
https://github.com/MushroomObserver/mushroom-observer/pull/718#discussion_r548764394
:

     copyright_holder: img.copyright_holder,

     "when(1i)" => img.when.strftime("%Y"),

     "when(2i)" => img.when.strftime("%m"),

     "when(3i)" => img.when.strftime("%d"),

     license_id: img.license_id

   }

 },

 log_change: { checked: "0" }

}

login(obs.user.name)
Image.any_instance.stubs(:save).returns(false)
post(:edit_observation, params: params)

assert_redirected_to(/#{obs.id}$/)
assert_equal(img_notes, img.reload.notes)

There is also a problem with my test (or maybe with the code being tested).
While I am covering the line, the assertion isn't what I want:
I'd like to assert that the flash has an Image error. But when I look at
the flash here, there's no Image error.
(And I think the assertion I wrote is actually testing whether stubs. So
I probably should get rid of it.)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#pullrequestreview-558724231,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNIHCIBAANRVK35RNTTSWPHJPANCNFSM4UKEMVWA
.

Doh! That makes sense.

Summary of some ideas in random order. (You're probably already doing some of these):

Demand that the location name include the county, If the geolocation is in the USA and a county is available;
(county is "available" if the user provides one or if Google returns one).
(I'm just guessing at what a reverse geocode provides. I need to review Google's documentation to see if I can begin to understand this.)
Demand that new/edited Observations in the USA locations include the state (not just the country). (We shouldn't have more Observations located in placed like "(Pacific Northwest, USA)[https://mushroomobserver.org/location/show_location/3876]".
Exclude from suggestions:

anything in a different country, state, or county than that obtained by a reverse geocode of the photo coordinates;
anything in a state different from that provided by Google or the User;
anything in a county different from that provided by Google or the User;
locations that are "too large".

I think I try to require county if one is present.  Google's API is highly
nonspecific as to what the various administration levels represent or if
they will be present.  I made a stab at it, at least.
I think I require state for countries in which we have the states listed.
I do NOT try to filter out nonsensical suggestions.
If google provides country/state/county and user does not, I think I do try
to suggest them(?) but maybe only if an existing location matches.
If google provides AND user provides AND they are different... I have no
idea what I do!  I wouldn't trust the user.  I might not always trust
google either, though.  Personally, I do trust google in the US (I use
reverse geolocate all the time in my private database system).  But things
get funny in other countries, so I don't want to try to force the user to
use what google provides.
There are times when I filter locations which are too large.  For example,
if the user provides gps but no location, it will find all existing
locations which contain that gps, then suggest only those with the largest
number of "terms" (= number of commas essentially).  I was far from
thorough about this, though.  There may be additional cases where "Earth"
will be suggested, and that will obviously be a mistake(!)
Does the structure of the code make sense at all?  I rewrote it from
scratch several times because the whole thing made my brain hurt so much.
But I think the latest incarnation has a certain compelling logic to it.
But there are empirically some cases not handled correctly, esp. as
concerns incorrectly-defined existing locations, a case I never considered
at any point in the process.
A few cases I know I need to investigate more are:

bogus existing locations
google and user disagree at country, state or county level
existing locations are only very vague but user has provided plausible
more accurate location

(A common mistake that might be worth checking for explicitly is forgetting
the minus sign on either longitude or latitude, or accidentally swapping
latitude and longitude.  I just did this myself a few weeks ago! I don't
recall handling it in the existing PR.)
But I'm sure there are more cases to consider.
On Fri, Dec 25, 2020 at 10:55 AM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

Summary of some ideas in random order. (You're probably already doing some
of these):

Demand that the location name include the county, If the geolocation
is in the USA and a county is available;
(county is "available" if the user provides one or if Google returns
one).
(I'm just guessing at what a reverse geocode provides. I need to
review Google's documentation to see if I can begin to understand this.)
Demand that new/edited Observations in the USA locations include the
state (not just the country). (We shouldn't have more Observations located
in placed like "(Pacific Northwest, USA)[
https://mushroomobserver.org/location/show_location/3876]".
Exclude from suggestions:

anything in a different country, state, or county than that
obtained by a reverse geocode of the photo coordinates;
anything in a state different from that provided by Google or the
User;
anything in a county different from that provided by Google or
the User;
locations that are "too large".

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-751265725,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNORWTXWR6IFLZTZDXDSWSYWXANCNFSM4UKEMVWA
.

Thanks for the feedback. I haven't yet dug into the code. That's the next.
I'm still thinking about what to suggest, and once we have all the suggestions, how to order them.
Ex: If user doesn't provide GPS, maybe suggestions should:

if possible include at least one suggestion at administrative level 2,
be ordered by area, ascending, with the default being the smallest.
I'm not sure. I'm still thinking about all of this, especially verbal specificity vs size.

The user can create an Observation with Location "Earth". Did you intend that? (I think not.) Ex:

Create Observation

Leave "Where" blank.
Add a photo that has geolocation. [This, and some of the following, steps might be unnecessary to reproduce the problem.]
Set Observation Date to image date
Set Observation Latitude/Longitude to image lat/lon
Click Create

Result: Create Observation form reloaded with Location problem form, and with Where: Earth

Click Create

Result: Create Observation form again reloaded with Location problem form, and with Where: Earth

Again Click Create

Result: Observation finally created with location: Earth

Should we ever fill in "Earth" in the Observation form place_name field?
(That might fix the above issue.)

Actually I'm not sure I have a problem with that.  We sure make it
difficult to use "Earth", but at least it never gets set to "NULL" or utter
garbage.
On Fri, Dec 25, 2020 at 4:42 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

Should we ever fill in "Earth" in the Observation form place_name field?
(That might fix the above issue.)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-751293144,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNI5ATH6PGKCGGI3VHLSWUBLTANCNFSM4UKEMVWA
.

Two cases where user doesn't fill in Where:

We have no lat/lon from the user (via either exif or manually entered). We don't have a way to supply a reasonable location, so our choices are to force them to supply something or accept Earth. I'm ok with Earth, but would prefer to send them in a loop until they give us a location. (I know that risks have nonsense supplied.)
We have lat/lon from user (either exif or manual). I think we can do better than Earth. Perhaps we fill in Where with the results of geocode or with the "best" LocationSuggestion? (I know that the geocode can be untrustworthy.) Or maybe we do this just for collections in the USA?

In the second case (user gives gps but no location) we do suggest a
rudimentary location even if it doesn't exist yet.  I think for the US it
gives park or city, county, state and country.  Try it out and see what you
think.  It's partly coded in javascript, and partly coded in ruby.  JS
interprets return from google in rough strokes, then passes it on to ruby,
who further refines based on whether we have a list of states for that
country or not.
There may be legitimate uses of "Earth" that we haven't foreseen, therefore
I would vote for accepting "Earth" in absence of any better alternative,
and after asking user to do better.  I was only expecting to ask the user
once, not twice.  But if it works that way currently, I'm not averse to
leaving it as-is.
On Fri, Dec 25, 2020 at 5:58 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

Two cases where user doesn't fill in Where:

We have no lat/lon from the user (via either exif or manually
entered). We don't have a way to supply a reasonable location, so our
choices are to force them to supply something or accept Earth. I'm ok with
Earth, but would prefer to send them in a loop until they give us a
location. (I know that risks have nonsense supplied.)
We have lat/lon from user (either exif or manual). I think we can do
better than Earth. Perhaps we fill in Where with the results of geocode or
with the "best" LocationSuggestion? (I know that the geocode can be
untrustworthy.) Or maybe we do this just for collections in the USA?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-751297742,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNIJM2RYABHKK7YUAATSWUKJNANCNFSM4UKEMVWA
.

Thanks! I won't tinker with Earth.
I'll dig into the code some more tomorrow.
On Fri, Dec 25, 2020 at 5:22 PM Jason Hollinger<EMAIL_ADDRESS>wrote:

In the second case (user gives gps but no location) we do suggest a
rudimentary location even if it doesn't exist yet. I think for the US it
gives park or city, county, state and country. Try it out and see what you
think. It's partly coded in javascript, and partly coded in ruby. JS
interprets return from google in rough strokes, then passes it on to ruby,
who further refines based on whether we have a list of states for that
country or not.
There may be legitimate uses of "Earth" that we haven't foreseen, therefore
I would vote for accepting "Earth" in absence of any better alternative,
and after asking user to do better. I was only expecting to ask the user
once, not twice. But if it works that way currently, I'm not averse to
leaving it as-is.
On Fri, Dec 25, 2020 at 5:58 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

Two cases where user doesn't fill in Where:

We have no lat/lon from the user (via either exif or manually
entered). We don't have a way to supply a reasonable location, so our
choices are to force them to supply something or accept Earth. I'm ok
with
Earth, but would prefer to send them in a loop until they give us a
location. (I know that risks have nonsense supplied.)
We have lat/lon from user (either exif or manual). I think we can do
better than Earth. Perhaps we fill in Where with the results of geocode
or
with the "best" LocationSuggestion? (I know that the geocode can be
untrustworthy.) Or maybe we do this just for collections in the USA?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-751297742
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AAYTNNIJM2RYABHKK7YUAATSWUKJNANCNFSM4UKEMVWA
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-751306881,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAALDFFNW7CYOSHMQB76FYTSWU3FNANCNFSM4UKEMVWA
.

This is so complex (probably necessarily so) that I can't keep it in my head.
I'm going to do some more manual testing, hoping that will help me.
I haven't yet looked at the geocoding you describe.
Thinking out loud, but these shouldn't delay the rollout.

Would it make sense to have suggestions be PORO?
Would it make sense to provide suggestions with all the user input, letting suggestions do the geocoding and some of the other work now performed by CreateAndEditObservation?

Good grief!  Missouri??  Sigh.
I like the sorted results, too.
I personally would vote for doing the sorting in rails.  The whole instance
should be available already.  We're only talking a small number of
suggestions, should not be too much of a performance such to sort by any
heuristics you can think up, no matter how convoluted!
On Sun, Dec 27, 2020 at 7:12 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

@JoeCohen commented on this pull request.
In app/models/location/suggestions.rb
https://github.com/MushroomObserver/mushroom-observer/pull/718#discussion_r549179611
:

       where("#{GRID_SQUARES} <= #{MAX_SUGGESTED_SIZE}").

       to_a

 # Return only most "precise" Locations.

 [3, 2, 1, 0].each do |n|

   locs = all.select { |loc| loc.name.split(",").length > n }

   return locs.sort_by(&:pseudoarea) if locs.any?

Is there a reasonable way to get the db to sort the results by size
ascending?
I'd rather have that done by the db than by Rails. But I couldn't figure
out the right syntax. Maybe it's so complex that we should just leave it to
Rails. There won't be a noticeable performance difference if there aren't
many "precise" hits.
I found it helpful to have the suggestions sorted by size. Compare
unsorted (good suggestions highlighted):
[image: Screen Shot 2020-12-27 at 16 01 06]
https://user-images.githubusercontent.com/45460/103182142-f4bb3500-485d-11eb-8415-627f41dbfd5c.jpg
to sorted:
[image: Screen Shot 2020-12-27 at 16 00 11]
https://user-images.githubusercontent.com/45460/103182120-bc1b5b80-485d-11eb-8380-df7e0854eace.jpg
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#pullrequestreview-558966120,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNOHLAFR3LS6U6HEKXDSW7EN7ANCNFSM4UKEMVWA
.

Agreed that it is too complex.  Did I mention I rewrote it from scratch
several times before even getting it this "simple"??
re: PORO = stand alone class or something like that?  If so, yes,
definitely.  I was struggling to pass all the necessary data around.  Would
be so much easier to have all that stuff just be owned by the instance of
some class.  Sorry, I really struggle with the activation energy to create
new classes for things.  Always feels like this huge extra overhead.  But
in this case, by the end, I definitely regretted not doing so.
re: division of labor between suggestions and controller -- By all means
move things around.  Just note that feedback occurs in multiple ways:

The vast majority of the time it's just a list of suggestions, and a
little text explaining why it's making these suggestions.
It can also auto-fill the "where" field if it was empty and we have
geocoding from google

Not that complicated, and now that I think of it, may help simplify things
if we separate out these two cases in the controller and call different
entry points into the suggestions public interface.
On Sun, Dec 27, 2020 at 7:20 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

This is so complex (probably necessarily so) that I can't keep it in my
head.
I'm going to do some more manual testing, hoping that will help me.
I haven't yet looked at the geocoding you describe.
Thinking out loud, but these shouldn't delay the rollout.

Would it make sense to have suggestions be PORO?
Would it make sense to provide suggestions with all the user input,
letting suggestions do the geocoding and some of the other work now
performed by CreateAndEditObservation?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-751533645,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNOLOHAKRKUQJ243LLDSW7FLBANCNFSM4UKEMVWA
.

Some Geocoding questions:

Can I do it directly from Rails. i.e., something like:

results = Geocoder.search([38.84952222222223, -123.63869444444445])

which would return something similar to:
 => [#<Geocoder::Result::Nominatim:0x0000563376a6b2d8 @data={"place_id"=>265241413, "licence"=>"Data © OpenStreetMap contributors, ODbL 1.0. https://osm.org/copyright", "osm_type"=>"way", "osm_id"=>10313835, "lat"=>"38.849467", "lon"=>"-123.638783", "display_name"=>"46599, Iversen Drive, Mendocino County, California, 95445, United States", "address"=>{"house_number"=>"46599", "road"=>"Iversen Drive", "county"=>"Mendocino County", "state"=>"California", "postcode"=>"95445", "country"=>"United States", "country_code"=>"us"}, "boundingbox"=>["38.849417", "38.849517", "-123.638833", "-123.638733"]}, @cache_hit=nil>]

If so, what (if any) configuration/setup so I need in order to have it work from my dev VM?

I Closed this PR by accident (and immediately re-opened). Sorry.

The point of doing it in JS is to have the client do it, not the server.
Maybe it doesn't take long, though?  And it doesn't hit the DB, which is
our weak link these days.
On Mon, Dec 28, 2020 at 2:59 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

Some Geocoding questions:

Can I do it directly from Rails. i.e., something like:

results = Geocoder.search([38.84952222222223, -123.63869444444445])
which would return something similar to:
=> [#<Geocoder::Result::Nominatim:0x0000563376a6b2d8 @data={"place_id"=>265241413, "licence"=>"Data © OpenStreetMap contributors, ODbL 1.0. https://osm.org/copyright", "osm_type"=>"way", "osm_id"=>10313835, "lat"=>"38.849467", "lon"=>"-123.638783", "display_name"=>"46599, Iversen Drive, Mendocino County, California, 95445, United States", "address"=>{"house_number"=>"46599", "road"=>"Iversen Drive", "county"=>"Mendocino County", "state"=>"California", "postcode"=>"95445", "country"=>"United States", "country_code"=>"us"}, "boundingbox"=>["38.849417", "38.849517", "-123.638833", "-123.638733"]}, @cache_hit=nil>]

If so, what (if any) configuration/setup so I need in order to have
it work from my dev VM?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-751846365,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNIXRLXK5ZVQRP3HGRLSXDPTLANCNFSM4UKEMVWA
.

Makes sense.
Is there a way to force it to happen when Where is blank but lat/lon is completed (ideally via photo or manually, but if it only works for photo, that's a start)?
The point is to be able to use the geocode results to reject some of the Suggestions, maybe also fill in Where.
Ex: User leaves Where blank, provides photo with lat/lon [38.84952222222223, -123.63869444444445]. The geocode results should let us
Reject:

Mono Creek Overflow, Sierra NF, Fresno Co, California, USA
Meeting of the Pines Natural Area, Michaux State Forest, Pennsylvania, USA
Chesterfield Post Office, Chesterfield, Missouri, USA
Fill in Where with:
Mendocino Co., California, USA

It is supposed to initiate a geocode request every time the lat/long is
changed.  It should additionally prevent submission until the result is
returned. It then stores the result in hidden form fields so that rails can
see the results.
On Mon, Dec 28, 2020 at 3:16 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

Makes sense.
Is there a way to force it to happen when Where is blank but lat/lon is
completed (ideally via photo or manually, but if it only works for photo,
that's a start)?
The point is to be able to use the geocode results to reject some of the
Suggestions, maybe also fill in Where.
Ex: User leaves Where blank, provides photo with lat/lon
[38.84952222222223, -123.63869444444445]. The geocode results should let us
Reject:

Mono Creek Overflow, Sierra NF, Fresno Co, California, USA
Meeting of the Pines Natural Area, Michaux State Forest,
Pennsylvania, USA
Chesterfield Post Office, Chesterfield, Missouri, USA
Fill in Where with:
Mendocino Co., California, USA

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-751850846,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNKI5NZRWEUYB5TRIULSXDRQVANCNFSM4UKEMVWA
.

Another idea, if you're worried about excessive google API requests, is to
actually wait until the user submits the form, then when they click "send",
it sends the google api request, waits for it, then submits.  Does that
work better for you?
On Mon, Dec 28, 2020 at 3:32 PM Jason Hollinger<EMAIL_ADDRESS>wrote:

It is supposed to initiate a geocode request every time the lat/long is
changed.  It should additionally prevent submission until the result is
returned. It then stores the result in hidden form fields so that rails can
see the results.
On Mon, Dec 28, 2020 at 3:16 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

Makes sense.
Is there a way to force it to happen when Where is blank but lat/lon is
completed (ideally via photo or manually, but if it only works for photo,
that's a start)?
The point is to be able to use the geocode results to reject some of the
Suggestions, maybe also fill in Where.
Ex: User leaves Where blank, provides photo with lat/lon
[38.84952222222223, -123.63869444444445]. The geocode results should let us
Reject:

Mono Creek Overflow, Sierra NF, Fresno Co, California, USA
Meeting of the Pines Natural Area, Michaux State Forest,
Pennsylvania, USA
Chesterfield Post Office, Chesterfield, Missouri, USA
Fill in Where with:
Mendocino Co., California, USA

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-751850846,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNKI5NZRWEUYB5TRIULSXDRQVANCNFSM4UKEMVWA
.

That seems reasonable, but wasn't on my mind.
Rather, I'm not seeing geocode data when I expect to see it. (I probably don't understand things.)
Here's what I'm seeing:

Start server
Create Observation
enter only Latitude: 38.84952, Longitude: -123.6387
click Create
Result:
With a breakpoint in CreateAndEditObservation like this:

   182:   def location_missing
   183:     @location_suggestion_reasons << :form_observations_location_missing.t
   184:     geo = geolocation(params)
   185: byebug

At this breakpoint I see:
   182:   def location_missing
   183:     @location_suggestion_reasons << :form_observations_location_missing.t
   184:     geo = geolocation(params)
   185: byebug
=> 186:     if geo[:country].present?
   187:       @place_name = Location.geolocation_to_name(geo)
   188:       @location_suggestions = Location.suggestions(@place_name, geo)
   189:       @place_name = Location.user_name(@user, @place_name)
   190:     end
(byebug) geo
{:country=>"", :state=>"", :county=>"", :city=>"", :latitude=>0.388495e2, :longitude=>-0.1236387e3}

You might check javascript console / errors.  Do you have a working google
API key?  Maybe something else is going wrong in javascript on your local
server.  You can add console.log("blah") to javascript to track progress
and state inside javascript.  Syntax is, as you probably know, very C-like.
On Mon, Dec 28, 2020 at 4:50 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

That seems reasonable, but wasn't on my mind.
Rather, I'm not seeing geocode data when I expect to see it. (I probably
don't understand things.)
Here's what I'm seeing:

Start server
Create Observation
enter only Latitude: 38.84952, Longitude: -123.6387
click Create
Result:
With a breakpoint in CreateAndEditObservation like this:

182:   def location_missing
183:     @location_suggestion_reasons << :form_observations_location_missing.t
184:     geo = geolocation(params)
185: byebug
At this breakpoint I see:
182:   def location_missing
183:     @location_suggestion_reasons << :form_observations_location_missing.t
184:     geo = geolocation(params)
185: byebug=> 186:     if geo[:country].present?
187:       @place_name = Location.geolocation_to_name(geo)
188:       @location_suggestions = Location.suggestions(@place_name, geo)
189:       @place_name = Location.user_name(@user, @place_name)
190:     end(byebug) geo{:country=>"", :state=>"", :county=>"", :city=>"", :latitude=>0.388495e2, :longitude=>-0.1236387e3}
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-751875023,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNIUFBUYNY2DWFLMKXTSXD4Q3ANCNFSM4UKEMVWA
.

How about try out a test script on the server to see how long a google
geocoder API request takes.  If it's on order tenths of a second to a
second, then this isn't worth screwing with.  Just move it all onto the
server.
On Mon, Dec 28, 2020 at 5:09 PM Jason Hollinger<EMAIL_ADDRESS>wrote:

You might check javascript console / errors.  Do you have a working google
API key?  Maybe something else is going wrong in javascript on your local
server.  You can add console.log("blah") to javascript to track progress
and state inside javascript.  Syntax is, as you probably know, very C-like.
On Mon, Dec 28, 2020 at 4:50 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

That seems reasonable, but wasn't on my mind.
Rather, I'm not seeing geocode data when I expect to see it. (I probably
don't understand things.)
Here's what I'm seeing:

Start server
Create Observation
enter only Latitude: 38.84952, Longitude: -123.6387
click Create
Result:
With a breakpoint in CreateAndEditObservation like this:

182:   def location_missing
183:     @location_suggestion_reasons << :form_observations_location_missing.t
184:     geo = geolocation(params)
185: byebug
At this breakpoint I see:
182:   def location_missing
183:     @location_suggestion_reasons << :form_observations_location_missing.t
184:     geo = geolocation(params)
185: byebug=> 186:     if geo[:country].present?
187:       @place_name = Location.geolocation_to_name(geo)
188:       @location_suggestions = Location.suggestions(@place_name, geo)
189:       @place_name = Location.user_name(@user, @place_name)
190:     end(byebug) geo{:country=>"", :state=>"", :county=>"", :city=>"", :latitude=>0.388495e2, :longitude=>-0.1236387e3}
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-751875023,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNIUFBUYNY2DWFLMKXTSXD4Q3ANCNFSM4UKEMVWA
.

I thought I had a working Google API key.

But it apparently doesn't work, either for MO development or elsewhere.

I must be doing something wrong on the Google side. I'll try to figure it out.

I had trouble with this, too.  I eventually copied over my personal key
that I use for my own lichen stuff, and that worked.  Just make sure not to
accidentally check in whatever you do! :)
On Mon, Dec 28, 2020 at 5:43 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

I thought I had a working Google API key.
[image: Screen Shot 2020-12-28 at 14 38 13]
https://user-images.githubusercontent.com/45460/103247037-580a9d00-491a-11eb-8343-7b8582e5a8db.jpg
But it apparently doesn't work, either for MO development or elsewhere.
[image: Screen Shot 2020-12-28 at 14 40 48]
https://user-images.githubusercontent.com/45460/103247195-e717b500-491a-11eb-8170-2ea54ca2726e.jpg
I must be doing something wrong on the Google side. I'll try to figure it
out.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-751886463,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNM2POPPRG5RSYA4KCDSXECZVANCNFSM4UKEMVWA
.

I had already put my key in config/gmaps_api_key.yml, under development and test.
Is that the right place?

I seem to remember needing to put it in two places?  Or was that the DB
password?
On Mon, Dec 28, 2020 at 6:18 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

I had already put my key in config/gmaps_api_key.yml, under development
and test.
Is that the right place?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-751893260,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNOUAG5FKVPOTGVGGYTSXEG4BANCNFSM4UKEMVWA
.

I don't know.
I'm going to put it to the side for now. It's too bewildering for me. 😢
On Mon, Dec 28, 2020 at 3:26 PM Jason Hollinger<EMAIL_ADDRESS>wrote:

I seem to remember needing to put it in two places? Or was that the DB
password?
On Mon, Dec 28, 2020 at 6:18 PM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

I had already put my key in config/gmaps_api_key.yml, under development
and test.
Is that the right place?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-751893260
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AAYTNNOUAG5FKVPOTGVGGYTSXEG4BANCNFSM4UKEMVWA
.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-751894643,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAALDFG2FGIUYNAIGX56JVDSXEHYPANCNFSM4UKEMVWA
.

@pellaea: As I'm a js complete novice, could you point me at the place where a geocode request every time the lat/long is changed.

Sorry, Joe, I just haven't had the time to follow all of this as closely as
I would like.  You're right, it does not do a geocode request each time the
lat/long is changed currently.  And in fact, if the map isn't open, the
code hasn't even been loaded yet, so there would be no way for it to do
so.
Look for updateFields() in
app/assets/javascripts/observation_form_map.js.erb.  It looks like it is
only called whenever someone... clicks or drags the pin on the map (via
addGmapsListener).
When the user uploads an image that has a lat/long in the EXIF, it creates
a radio button of some sort, and when the user clicks on it, it will popup
it's very own (separate) map showing where that location is on the map (but
does nothing with this!).  There is another button somehow associated
with these radio buttons (it's very hard to picture what the layout looks
like when dynamically generated with jQuery code!) that, when pressed, will
set observation_lat, observation_long, observation_alt and then hide the
EXIF radio button controls.  But as there are no callbacks associated with
those fields, nothing further happens.  The map shouldn't even be updated
if open, if I'm reading this right.
If we do what I originally suggested, we could pull the geocode stuff out
of updateFields(), and attach it to the observation_lat and
observation_long fields instead.  Then no matter how those fields are
changed -- by hand, by clicking on dragging the pin, or by selecting one of
the EXIF lat/long controls -- it will trigger the geocode.
Alternatively, move the geocode request from updateFields() to the submit
button.  Have it wait until the user submits the form, then, if the user
has changed either the lat/long or where fields, have it postpone
submission and first make a geocode request, then submit the form when that
request returns or after a short timeout period, with a twirly thing
displayed in the meantime to let the user know it's thinking.  (That is
already mostly in place, because I already have it delay submission until
the geocode request is finished.  But the geocode request is initiated only
by clicking/dragging the pin on the map, apparently.)
Lastly, we can do away with the geocode on the server instead and avoid the
whole javascript problem.  But again, I would advise at least testing how
quickly google responds.  It would be poor form to have server instances
held up for seconds twiddling their thumbs while waiting for google!
Hmmm.  Although... If this is a significant problem, note that waiting
takes no server resources (just memory which I think is no longer
limiting), so we could potentially offset the average "waiting for google"
time by adding additional server instances.  That bears consideration...
Phew, that's a mouthful.  Sorry.  And sorry I didn't dive into this more
deeply earlier.  Good news is I just finally finished and sent off last
night a big paper revising part of genus Anaptychia, a paper I've been
working on (initially with Alan's help at CCL actually! :) for over 5
years.  Of course, there are two additional papers that are high
priority...  It never ends!
On Wed, Dec 30, 2020 at 9:53 AM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

@pellaea https://github.com/pellaea: As I'm a js complete novice, could
you point me at the place where a geocode request every time the lat/long
is changed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-752649084,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNKVMCDRP7VWFJUHKLDSXM5HDANCNFSM4UKEMVWA
.

Thanks so much! That's a huge help for me.
Now I have potential paths forward to help with this branch; before I felt I was at a dead end.
And congratulation on the Anaptychia paper. I'll have to figure out what Anaptychia are; it's another way for me to procrastinate :-)

Nastassja wants to entitle the paper "Musical Chairs: Two new species of
Anaptychia from the Great Basin Desert, U.S.A."  That's how messed up the
taxonomy is in NA right now!
On Wed, Dec 30, 2020 at 11:07 AM Joseph D. Cohen<EMAIL_ADDRESS>wrote:

Thanks so much! That's a huge help for me.
Now I have potential paths forward to help with this branch; before I felt
I was at a dead end.
And congratulation on the Anaptychia paper. I'll have to figure out
what Anaptychia are; it's another way for me to procrastinate :-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-752674513,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNIVXDHAB4T566RNSMLSXNF3BANCNFSM4UKEMVWA
.

Coverage increased (+0.09%) to 93.046% when pulling 436c64e68f8a5bceba48a9261834dcc9c3a0c576 on location-name-suggestions into e2db3a9d1509fac36b494a5eab11618d95acbedc on master.

Coverage increased (+0.09%) to 93.046% when pulling 436c64e68f8a5bceba48a9261834dcc9c3a0c576 on location-name-suggestions into e2db3a9d1509fac36b494a5eab11618d95acbedc on master.

Manually resolved (in Codeclimate) as Invalid.
These are both false positives due to Codeclimate running an older version of Brakeman.
They are not issues in Brakemen 5.2.3

Code Climate has analyzed commit 65e57ee and detected 2 issues on this pull request.
Here's the issue category breakdown:
Category	Count
Security	2
Note: there is 1 critical issue.
View more on Code Climate.

Is this PR worth reviving?  It sure seems like it.

Definitely. This would improve the quality of many Observations and avoid
some correction of Observations by admins and regular users.
On Wed, May 10, 2023 at 12:43 PM andrew nimmo @.***>
wrote:

Is this PR worth reviving? It sure seems like it.
—
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-1542712465,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAALDFGKVSWOJR2SSRYJCR3XFPVWLANCNFSM4UKEMVWA
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

Yes and no.  I learned a lot while doing it, but it was way
over-engineered.  I think if I were to pick this back up I would start over
from scratch and do something much simpler... i.e., not incurring so much
technical obligation.  That's my opinion.
Is the PR description clear?  The whole point is to help people not
misspell location names.  But the fuzzy match I did for species names
doesn't really work for locations, because leaving a single word out is
"minor" for location names but causes the Levenstein distance to be huge.
"Close" matches according to Levenstein distance are just off by a few
letters, not entire words.  And things like spelling of "county" shouldn't
count against the match.  And we know all the country names and even state
names for many countries.  And so on.  So I went a little crazy.  There
must be a better way to solve this general problem.
On Wed, May 10, 2023 at 4:10 PM Joseph D. Cohen @.***>
wrote:

Definitely. This would improve the quality of many Observations and avoid
some correction of Observations by admins and regular users.
On Wed, May 10, 2023 at 12:43 PM andrew nimmo @.***>
wrote:

Is this PR worth reviving? It sure seems like it.
—
Reply to this email directly, view it on GitHub
<
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-1542712465
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AAALDFGKVSWOJR2SSRYJCR3XFPVWLANCNFSM4UKEMVWA
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

—
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-1542746145,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNI3XHSRZNT4AST3WCTXFPY4VANCNFSM4UKEMVWA
.
You are receiving this because you were mentioned.Message ID:
@.***>

I get it. One option people seem to use is to have Google Maps API validate the place name. I'm not crazy about tying our data to Google but i guess open to it for expedience if others feel like it's a good idea. On May 10, 2023, at 7:40 PM, Jason Hollinger @.***> wrote:
Yes and no.  I learned a lot while doing it, but it was way
over-engineered.  I think if I were to pick this back up I would start over
from scratch and do something much simpler... i.e., not incurring so much
technical obligation.  That's my opinion.
Is the PR description clear?  The whole point is to help people not
misspell location names.  But the fuzzy match I did for species names
doesn't really work for locations, because leaving a single word out is
"minor" for location names but causes the Levenstein distance to be huge.
"Close" matches according to Levenstein distance are just off by a few
letters, not entire words.  And things like spelling of "county" shouldn't
count against the match.  And we know all the country names and even state
names for many countries.  And so on.  So I went a little crazy.  There
must be a better way to solve this general problem.
On Wed, May 10, 2023 at 4:10 PM Joseph D. Cohen @.***>
wrote:

Definitely. This would improve the quality of many Observations and avoid
some correction of Observations by admins and regular users.
On Wed, May 10, 2023 at 12:43 PM andrew nimmo @.***>
wrote:

Is this PR worth reviving? It sure seems like it.
—
Reply to this email directly, view it on GitHub
<
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-1542712465
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AAALDFGKVSWOJR2SSRYJCR3XFPVWLANCNFSM4UKEMVWA
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

—
Reply to this email directly, view it on GitHub
https://github.com/MushroomObserver/mushroom-observer/pull/718#issuecomment-1542746145,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYTNNI3XHSRZNT4AST3WCTXFPY4VANCNFSM4UKEMVWA
.
You are receiving this because you were mentioned.Message ID:
@.***>

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>


usage of $inject in 0.10.7 controllers

I was playing around with 10.7 and was trying to figure out why my controllers scope object was being trounced
function Ctrl($scope) {
}
Ctrl.$inject = [];
I figured out that it has to do with $inject . Am I correct to assume that $inject should always have '$scope' leading the injections?
--dan

The change you are experiencing is that the local scope is being injected
as any other services instead of being the this in the controller. That
means that if you do minify your code then you have to specify $inject
property that includes $scope identifier

yes
function Ctrl($scope) {
}
Ctrl.$inject = ['$scope'];
2012/2/1 dandoyon <
<EMAIL_ADDRESS>

I was playing around with 10.7 and was trying to figure out why my
controllers scope object was being trounced
function Ctrl($scope) {
}
Ctrl.$inject = [];
I figured out that it has to do with $inject . Am I correct to assume that
$inject should always have '$scope' leading the injections?
--dan

Reply to this email directly or view it on GitHub:
https://github.com/angular/angular.js/issues/740


DNS Request App - Request Validation

User Need
As a ops eng team member
I want requests that come in through the dns request app to be valid
so that dns requests cna be efficiently enacted
Acceptance Criteria:

Ensure that form fields are validated before issue creation e.g. email field

@AntonyBishop we should probably take requestor email as input aswell?

We totally should.


Support task attr for StreamResponse

#1027

Current coverage is 98.88% (diff: 100%)

Merging #1410 into master will increase coverage by <.01%

@@             master      #1410   diff @@
==========================================
  Files            30         30
  Lines          6892       6900     +8
  Methods           0          0
  Messages          0          0
  Branches       1143       1143
==========================================
+ Hits           6815       6823     +8
  Misses           33         33
  Partials         44         44

Powered by Codecov. Last update 5ca636a...6130824


Getting "No such payment_intent: 'pi_3LiNiUDBzg8BxVzZ0fADyJQb'" on retrievePaymentIntent

Describe the bug
Getting "No such payment_intent: 'pi_3LiNiUDBzg8BxVzZ0fADyJQb'" on retrievePaymentIntent after creating the payment intent on server side.
To Reproduce
Steps to reproduce the behaviour:
const { error } = await discoverReaders({
discoveryMethod: 'bluetoothScan',
simulated: true
});
const { reader, error } = await connectBluetoothReader({
reader: data,
});
const response = await createReaderIntentService(obj); // getting secret from server side
const retrievedResponse = await retrievePaymentIntent(response?.client_secret);
console.log('\n\n\n\n   retrievePaymentIntent response ', retrievedResponse);
log:  {"error": {"code": "PAYMENT_ERROR.DECLINED_BY_STRIPE_API", "message": "No such payment_intent: 'pi_3LiNiUDBzg8BxVzZ0fADyJQb'"}, "paymentIntent": undefined}
Expected behaviour
Payment intent should be retrieved after creating it at backend and passing retrievePaymentIntent function client secret.
Screenshots
If applicable, add screenshots to help explain your problem.

Smartphone (please complete the following information):

Device: Tecno camon 17 and huawei honor 7c
OS: Android 12 and Android 8
WisePad3 BT Simulator

Hi @abdulrafeh857 -- looking at our logs, it appears the Payment Intent was created under a different account that you were using to retrieve it. Please make sure that you're using the same secret key for creating connection tokens and creating Payment Intents in your backend. I'm going to optimistically close this issue.

Hi, thanks for input, turns out that device was registered on main account and payment intent was created on a connected account. Thanks for pointing out.


VQA evaluation doesn't print accuracy

I am trying to replicate the VQAv2 evaluation by running bash run_scripts/pnp-vqa/eval/eval_vqav2.sh. However, the scores aren't printed out. I only get:
...
result file saved to /home/LAVIS/lavis/output/PNP-VQA/VQAv2_val/20221124171/result/val_vqa_result.json
loading VQA annotations and questions into memory...
creating index...
index created!
Loading and preparing results...
DONE (t=0.42s)
creating index...
index created!
computing accuracy
Finshed Percent: [####################] 99% Done computing accuracy
NCCL INFO [Service thread] Connection closed by localRank 0
NCCL INFO comm 0x7fa08c008fb0 rank 0 nranks 8 cudaDev 0 busId e00000 - Abort COMPLETE

Is this expected behavior? If so, where do I find the final scores? Thanks!

Hi @AaronLiu1997 ,  thanks for your interest.
You should be able to see the metric under the output folder.
Thanks.


released discussion solution

pr for discussion #11 solution release.

@mihranmiroyan @rohanjha123 Hi Mir and Rohan! I don't have GitHub push access, would appreciate if this pr can be merged in a timely manner, and I can be granted access. Thanks.


Register as npm package

Is there a npm install glidejs?
thanks

You can install glide via bower.

who still uses bower nowadays : ).
Btw, I like your plugin. thank you.

I agree, bower has become obsolete - npm package would be ideal.

This work fine:
npm install github:jedrzejchalubek/Glide.js

I've published it under original name as it is in package.json. If author need this name on npm later -- I will give it to him. But now I cant wait while someone does this

Package published :)
https://www.npmjs.com/package/glidejs

Please, document official package.

Is it possible to get the most recent version pushed to NPM?
What is the recommended way of pulling this package for builds?


Fixes issue #16

Rewrite the way timers keep track of time, preventing interference caused by intrinsic delays on app launch, background, persist tasks, system timer scheduling, etc.

This looks great! I'm going to review this as soon as I get a chance. Thanks for doing this.

I'm glad to be able to help improve this app.


Add support for Vector3

May add support Vector3 type;
Vector3 is System.Numerics.Vector3;

IMPL -> c62030b7a829e04b7df03b8323629f6f4dda35e9


Not render in Chrome with Kentico CMS 7.x

Hi,
I am using Build forms from JSON Schema(downloaded from https://github.com/joshfire/jsonform). I have integrated this into Kentico CMS 7.x. it is working fine in IE and Firefox browsers but not working in Chrome and safari (no script errors).
Please help me.
Thanks
Vasu

We don't really have knowledge on Kentico CMS. If this is still an issue and you are still using this lib, feel free to repoen and give us some more details on the error


[BUG] Low-pri: NUTS regions only in EU countries

This works well on Map tool:

Best solution might be to come up with a config of containment types & equivalence -- Eurostat NUTS is not a common term, so it might be nicer to say instead "Country" "Provinces / States" etc

fixed


Quote marks in JobId will break code

If I use this:
[RecurringJob("*/5 * * * *", "GMT", "Priority", "Data\"Retention")]

The generated code will not compile. Consider use SymbolDisplay.FormatLiteral to properly escape strings.

Thanks, will take a look some time.
But open to a PR if u want.

It’s actually not nothing I need, just something I discovered and wanted to let you know. 🙂


Ability to download specified FFmpeg version

Blaze needs to download a specified version of FFmpeg-static and unzip it. It then needs to then use this folder and the ffmpeg.exe inside it to optimize resources through command-line.

FFmpeg will ship with it instead.


Figma Project Draft for Website Design-2

This is the continuation of issue number 11

We have two same issue , #26  and #27 are same.

A design change has been made for the corporate website. This issue is now considered invalid.


TCK-CPP: Implement Account JSON-RPC Service

Problem
At the moment endpoints for any kind of Hedera related transactions and queries are being held by the sdkClient. We should  introduce endpoint grouping.
Solution
We should create an Account JSON-RPC Service to hold Account specific endpoints.
Alternatives
No response

Need more discussion


Advanced layout strategies (grid, floating text, etc.)

Currently, iced_native only supports flexbox items. For instance, it is not possible to create a grid of items or make text float around an image.
We will need to enhance the layouting engine to support different strategies and improve the way we measure text to lay it out in a more flexible way.

I like to mentionelm-ui for inspiration – as an alternative to CSS concepts.
There is also a talk from its author on youtube.

A, kindly ignore. I just saw that elm-ui is already on your radar. :)

You may wish to consider using https://github.com/vislyhq/stretch for layout. It's a full flexbox implementation, with support for absolute positioning. CSS grid support is stated goal, although it's not currently implemented.

@hecrj I've been looking into what it would take to implement Taffy's layout modes (Flexbox and CSS Grid) as an Iced widget. I have a working prototype of a Grid widget at https://github.com/nicoburns/iced_taffy (checkout the nested example if you are interested).
Based on the experience of making this prototype I have a bit of a laundry list of changes to Iced that I'd like in order to make such an integration easier and more efficient:

Add a measure method to Widget trait
This would be similar to layout, but only returns a size rather than recursively returning child layouts. Taffy's layout modes often require measuring children multiple times so it's important that this is as cheap as possible. And it is often much cheaper to merely compute the size of widget than it is to recursively layout the widget and all of it's descendants.
This method should take &mut self rather than &self to enable caching of the results. The caching is useful even within a single frame (/relayout) and is crucial for performance (in our benchmarks it turns the time complexity of layout from "exponential with respect to the depth of the tree" to "linear with respect to the total number of nodes" leading to wall time improvements of several orders of magnitude for trees even a few nodes (e.g. 7) deep).

Have the layout method on Widget trait take &mut self instead of &self (possibly not currently useful)
Same reason (caching) as above. Although I'm not quite sure what Iced's story on change detection is. I think I read somewhere that Iced currently unconditionally rerenders everything on each frame, in which case this may not be useful yet.

Add setters for fill property of layout::Limits
I need precise control of the Limits beyond what is provided by the current methods. I'm currently working around this by carefully calling multiple methods, but this is quite awkwards.

Ability to move children out of layout::Node
I need to obtain the recursive child layouts out of layout::Node but override the bounds with my own computations. I am currently able to workaround this by cloning the children Vec, but this introduces an unncessary clone.

There are other things I'd potentially like in future such as:

Extra parameters to layout/measure that make it possible to request both a "min-content" and "max-content" size from a child (which enables better content-sizing of widgets that support wrapping).
Support for clipping a widget such that it's restricted to rendering within certain bounds
Better support for rendering multiple layers of content so that we can support position: absolute or some similar layer mechanism

But I believe the above (particularly the measure method) would be sufficient to get to the point where I could sensibly release a generally usable version of iced_taffy with acceptable performance for large trees.
Would you be open to PR's that made these changes?

Update: Just saw https://github.com/iced-rs/iced/pull/52 and wanted to add that:

The performance issues have been solved in recent versions of Taffy (see benchmarks)
The "all or nothing" nature of Taffy is also in the process of being fixed. Once this PR (https://github.com/DioxusLabs/taffy/pull/326) lands it will be possible to use Taffy to layout a single widget much like Iced's existing Row/Column widget work, which will mean that Taffy's layout modes can be mixed and matched with other simpler layout modes as desired. The iced_taffy prototype is based on this branch.

Hi @videni Did you manage to achieve this? I also need to implement this in my project

@sauntheninja2 , I integrated taffy, it works as expected, but it still in earlier age,  demo only purpose ,  it is lack of crical features:

Don't recaculate layout size if no layout related changes.
I think we can get the cache of taffy and save it to the state of iced widget.
infinite load, load more data as nessary.
you can check the official list widget to implement this feature
Render children only visible in viewport.
again , check the list widget if you want this feature.

if you like ,  here is the gist about the naive implemention


Configuration flags not forwarded to rust compiler

Configuration flags are not forwarded to rust compiler. To test this I created this repo: phroi/capsule-feature-error.  The following test script:
use crate::error::Error;
use core::result::Result;

const RESULT: Result<(), Error> = if cfg!(myfeature) {
    Ok(())
} else {
    panic!("myfeature not found in command line args");
};

pub fn main() -> Result<(), Error> {
    return RESULT;
}

Compiled with the following command:
capsule build --release -- --features myfeature

Or with:
capsule build --release

Results in the same kind error:
$ capsule build --release -- --features myfeature
Building contract capsule-feature-error
RUSTFLAGS=--remap-path-prefix=/home/user=~ --remap-path-prefix=/home/user/capsule-feature-error=
$ cross build -p capsule-feature-error --release --features myfeature
   Compiling capsule-feature-error v0.1.0 (/home/user/capsule-feature-error/contracts/capsule-feature-error)
error[E0080]: evaluation of constant value failed
 --> contracts/capsule-feature-error/src/entry.rs:7:5
  |
7 |     panic!("myfeature not found in command line args");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'myfeature not found in command line args', contracts/capsule-feature-error/src/entry.rs:7:5
  |
  = note: this error originates in the macro `$crate::panic::panic_2021` which comes from the expansion of the macro `panic` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0080`.
error: could not compile `capsule-feature-error` due to previous error
error: command exited with non-zero code `cross build -p capsule-feature-error --release --features myfeature`: 101

Keep up the great work :muscle:
Phroi
PS: of course the use of panic is not the issue here. This can be proven by inverting the two linesOk(()) and panic!("myfeature not found in command line args"); and noticing that it compiles just fine.

https://rust-lang.github.io/rfcs/3013-conditional-compilation-checking.html
correct version:
#[cfg(feature = "myfeature")]

@XuJiandong that's actually works, thanks a lot!!
I may be wrong, but in my opinion the behavior changed since I started developing iCKB :thinking:
With Capsule 0.9.0 it was still generating the correct contract with the syntax cfg!(myfeature)], I know this as I tested all iCKB functionalities on a devnet. Now on Capsule 0.10.1 the same setup would generate a contract for mainnet (which is the default when no feature is specified), so it cannot possibly work on a devnet.


Solidity

What programming language should we add?
Solidity
What is the official website for the language?
https://soliditylang.org/
Is this a language that comes in many variants? If so, which variant should we support?
It has versions which can be defined.
Does the language have an official logo? If so

please include a link to an example
https://soliditylang.org/images/SolBlueGradient.png
https://soliditylang.org
please list the attribution rights of that logo
https://docs.soliditylang.org/en/latest/brand-guide.html
Does the language have an unofficial logo? If so
No
please explain the ways in which people use the unofficial logo
please include a link to an example
please list the attribution rights of that logo

Is there a testing framework available for the language?
Yes - truffle, hardhat and more
Is this language listed as 'supported' by Prism.js? If so
Yes

what is Prism's canonical spelling for the language?
solidity
what file extensions should be highlighted?
sol
If it is not supported by Prism.js, what is the closest supported language it maps to?

Who will be leading the effort to launch the track?
Me -  Ali Azam

New track at https://github.com/orgs/exercism/teams/solidity :)
Drop<EMAIL_ADDRESS>an email and he'll help you get started :)

Thanks @iHiD , Email sent to @ErikSchierboom , Looking forward to it!

How can I help with this track?

@adidoes Great! Could you send an email to<EMAIL_ADDRESS>I'll then help you get started.

See https://github.com/exercism/request-new-language-track/issues/80 for the original issue.

The work to launch this track was never completed, and there has been no activity on the track for a long time.
We are therefore archiving the track repository.
If someone wants to actively build and launch this track, please open an issue in https://forum.exercism.org/c/exercism/building-exercism/125 to discuss it.


find_boost 1.69

Building a project that depends on boost does not work because cmake is not able to find boost.
The error is:
CMake Warning at C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/FindBoost.cmake:847 (message):
New Boost version may have incorrect or missing dependencies and imported
targets
Call Stack (most recent call first):
C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/FindBoost.cmake:959 (_Boost_COMPONENT_DEPENDENCIES)
C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/FindBoost.cmake:1618 (_Boost_MISSING_DEPENDENCIES)
C:/Sandbox/GitHub/vcpkg/scripts/buildsystems/vcpkg.cmake:197 (_find_package)
ompl/CMakeModules/FindPython.cmake:179 (find_package)
CMakeLists.txt:83 (find_boost_python)

Hi @jcsantamaria, can you provide more information for this issue? How did you build this project?

I am manually executing the steps described here: ompl
In a powershell, I prepare the context:
./vcpkg env --triplet x64-windows set platform=x64 set CTEST_OUTPUT_ON_FAILURE=1 set CMAKE_TOOLCHAIN_FILE=-DCMAKE_TOOLCHAIN_FILE="c:\Sandbox\GitHub\vcpkg\scripts\buildsystems\vcpkg.cmake" set CMAKE_GENERATOR=-G"Visual Studio 15 2017 Win64" set VCPKG_ARCH=x64-windows
Then, created a build folder and executed:
cmake %CMAKE_GENERATOR% -DCMAKE_BUILD_TYPE=%configuration% %CMAKE_TOOLCHAIN_FILE% -DOMPL_REGISTRATION=OFF ..
These are the versions of tools reported by cmake:
-- The CXX compiler identification is MSVC 19.16.27030.1 -- The C compiler identification is MSVC 19.16.27030.1 -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx86/x64/cl.exe -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Building Release -- Found Eigen3: C:/Sandbox/GitHub/vcpkg/installed/x64-windows/include/eigen3 (Required is at least version "2.91.0")  -- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)  -- Could NOT find FLANN (missing: FLANN_LIBRARIES FLANN_INCLUDE_DIRS)  -- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)  -- Could NOT find SPOT (missing: SPOT_LIBRARIES SPOT_INCLUDE_DIRS)  -- Found PY_numpy: C:\ProgramData\Anaconda3\lib\site-packages\numpy\__init__.py   -- Could NOT find PY_pyplusplus (missing: PY_PYPLUSPLUS)  -- Could NOT find PY_pygccxml (missing: PY_PYGCCXML)  -- Could NOT find castxml (missing: CASTXML)
But the

New Boost version may have incorrect or missing dependencies and imported

message appears multiple times:
C:\Sandbox\ompl-1.4.1\build>cmake %CMAKE_GENERATOR% -DCMAKE_BUILD_TYPE=%configuration% %CMAKE_TOOLCHAIN_FILE% -DOMPL_REGISTRATION=OFF .. -- Building Release CMake Warning at C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/FindBoost.cmake:847 (message):   New Boost version may have incorrect or missing dependencies and imported   targets Call Stack (most recent call first):   C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/FindBoost.cmake:959 (_Boost_COMPONENT_DEPENDENCIES)   C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/FindBoost.cmake:1618 (_Boost_MISSING_DEPENDENCIES)   C:/Sandbox/GitHub/vcpkg/scripts/buildsystems/vcpkg.cmake:197 (_find_package)   CMakeLists.txt:62 (find_package) CMake Warning at C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/FindBoost.cmake:847 (message):   New Boost version may have incorrect or missing dependencies and imported   targets Call Stack (most recent call first):   C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/FindBoost.cmake:959 (_Boost_COMPONENT_DEPENDENCIES)   C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/FindBoost.cmake:1618 (_Boost_MISSING_DEPENDENCIES)   C:/Sandbox/GitHub/vcpkg/scripts/buildsystems/vcpkg.cmake:197 (_find_package)   CMakeLists.txt:62 (find_package) CMake Warning at C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/FindBoost.cmake:847 (message):   New Boost version may have incorrect or missing dependencies and imported   targets Call Stack (most recent call first):   C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/FindBoost.cmake:959 (_Boost_COMPONENT_DEPENDENCIES)   C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.12/Modules/FindBoost.cmake:1618 (_Boost_MISSING_DEPENDENCIES)   C:/Sandbox/GitHub/vcpkg/scripts/buildsystems/vcpkg.cmake:197 (_find_package)   CMakeLists.txt:62 (find_package)
I hope this helps.

I kept digging into this.
The build is using the installed version of CMake (cmake-3.12).
The FindBoost.cmake in the Modules folder of the CMake tool has these lines (starting at 846):
   if(NOT Boost_VERSION VERSION_LESS 106900)       message(WARNING "New Boost version may have incorrect or missing dependencies and imported targets")     endif()
So, it appears that the accompanying CMake tool to Visual Studio 2017 (version 15.9.11) is not configured to use boost 1.69 or above.
It appears that support for boost 1.69 was added to CMake 3.13: https://gitlab.kitware.com/cmake/cmake/merge_requests/2522

Hi @jcsantamaria, thanks for posting this issue. Could you update CMake to the latest version ( It is 3.14.0 now in vcpkg ) and try it again?

Please feel free to reopen it if this is still a problem for you.

Hi @NancyLi1013, I'm getting this warning again with the latest VS 2022, its integrated CMake (3.24), and the latest Boost from vcpkg (1.80):
CMake Warning at C:/Program Files/Microsoft Visual Studio/2022/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.24/Modules/FindBoost.cmake:1384 (message):
1> [CMake] New Boost version may have incorrect or missing dependencies and imported targets

This is a normal warning when using a version of boost newer than the one requesed with find_package.
It is not an error by itself, but can be a useful piece of information in the case of unexpected errors.

To be honest I find it a rather annoying and (in most cases) unnecessary warning. It completely clutters up the terminal output of CMake - it's not just the above two lines but an 11-line warning with call stack. In normal operation, this warning is unnecessary and just clutter, and it actually hides potentially more important things in the CMake configure output. At the minimum, there should be an option to suppress this warning, or, it shouldn't be enabled by default, there should be an opt-in debug-logging switch for this.

This warning is from the FindBoost.cmake module in CMake, not from vcpkg.
https://github.com/Kitware/CMake/blob/48c69eeafe5e480b5baa0c6766d4d2e3c7f5a4ad/Modules/FindBoost.cmake#L1383-L1385
The variable to disable this warning exists since CMake 3.20
https://cmake.org/cmake/help/latest/module/FindBoost.html

That's great, thank you very much @dg0yt! (I still wish the warning was opt-in as opposed to opt-out, but the variable is good enough.)

I also didn't know about the variable until now. Sometimes it is annoying to have these stack traces in vcpkg logs because they make it more difficult to see the actual errors. So I really wonder if it would be appropriate for vcpkg to print a clear STATUS message (stdout, no call stack) in instead of the WARNING (stderr, callstack) when the variable is unset. This could be implemented in a wrapper. It is vcpkg's responsibility to take care of boost port dependencies.


Prevent version notification message when there is no change

Indeed, reloading extensions in developer mode triggers a notification. However, I believe that "updates without version upgrades" rarely occur in normal user usage.
I think that this feature should be kept for the following reasons:

For debugging notification functions.
To give users an opportunity to question the update if an update is made in the same version due to unforeseen circumstances.

Is it bothersome to receive notifications every time you reload?

Yeah, seems reasonable. The normal end user would rather install from extension store, so keeping this way is better for debugging purposes.


Update ohw.values.yaml, new R image and "funded by" info

Updates for 2024 OHW24-in-Spanish events.
Add R packages and update "Funded by" organization and url to CSIC
xref https://github.com/2i2c-org/infrastructure/issues/4883 and https://github.com/oceanhackweek/jupyter-image/pull/93

Thanks!


Expose initial_guess option in proxqp

See https://simple-robotics.github.io/proxsuite/md_doc_22-ProxQP__api.html#OverviewInitialGuess . As that is an enum setting, we should add support for string settings to the parameter methods.

fyi @LoreMoretti


[WIP] MGUsup

PR Summary
Included code and documentation for a Mie-Gruneisen EOS based on a linear Us-up relation.
It is a full EOS with consistent temperature.

PR Checklist

[ x] Adds a test for any bugs fixed. Adds tests for new features.
[ x] Format your changes by using the make format command after configuring with cmake.
[ x] Document any new features, update documentation for changes made.
[ ] Make sure the copyright notice on any files you modified is up to date.
[ ] After creating a pull request, note it in the CHANGELOG.md file.
[ ] LANL employees: make sure tests pass both on the github CI and on the Darwin CI

If preparing for a new release, in addition please check the following:

[ ] Update the version in cmake.
[ ] Move the changes in the CHANGELOG.md file under a new header for the new release, and reset the categories.

@aematts as this is marked WIP do you want review now? Or do you want us to wait? I see @jhp-lanl already reviewed. :)

@aematts as this is marked WIP do you want review now? Or do you want us to wait? I see @jhp-lanl already reviewed. :)

I want reviews but not merge just yet. I am fixing the documentation since I am only using the pipeline for compiling it. So I need to do some commits more. I will remove the WIP when I am ready for merge.

And both of you: THANKS for getting on it so fast.

@aematts as this is marked WIP do you want review now? Or do you want us to wait? I see @jhp-lanl already reviewed. :)

I want reviews but not merge just yet. I am fixing the documentation since I am only using the pipeline for compiling it. So I need to do some commits more. I will remove the WIP when I am ready for merge.

:+1: Understood. I will make sure to review this by the end of today.

I have two more questions:

where do I find the correct copyright text for updating the copyright notice?
I do not know how to run on the GPUs on Darwin so can someone else make sure this run correctly on Darwin?
(There are a few failed tests that I have not touched at all and they failed already before I started working on the files. What do I do with these?)

1. where do I find the correct copyright text for updating the copyright notice?

Just copy the old one and update the date to 2024. Just worry about the files you change. We'll do an automated update later.

2. I do not know how to run on the GPUs on Darwin so can someone else make sure this run correctly on Darwin?
   (There are a few failed tests that I have not touched at all and they failed already before I started working on the files. What do I do with these?)

It's easiest to use the gitlab CI. I'll post some instructions in mattermost for how to do this.

I have two more questions:
1. where do I find the correct copyright text for updating the copyright notice?

All this means is that in each file you touch, make sure that there's a blurb like the one below. And that the date includes the current calendar year as the end date... e.g., 2024.
//------------------------------------------------------------------------------
// © 2021-2024. Triad National Security, LLC. All rights reserved.  This
// program was produced under U.S. Government contract 89233218CNA000001
// for Los Alamos National Laboratory (LANL), which is operated by Triad
// National Security, LLC for the U.S.  Department of Energy/National
// Nuclear Security Administration. All rights in the program are
// reserved by Triad National Security, LLC, and the U.S. Department of
// Energy/National Nuclear Security Administration. The Government is
// granted for itself and others acting on its behalf a nonexclusive,
// paid-up, irrevocable worldwide license in this material to reproduce,
// prepare derivative works, distribute copies to the public, perform
// publicly and display publicly, and to permit others to do so.
//------------------------------------------------------------------------------

2. I do not know how to run on the GPUs on Darwin so can someone else make sure this run correctly on Darwin?

Yeah I will trigger the tests. I can also walk you through how to do it at some point. The way to do it is to push your branch to the mirror on re-git and create a pull request there. We never merge that PR but it will trigger the Darwin tests and report their status. I did it for this branch here:
https://re-git.lanl.gov/xcap/oss/singularity-eos/-/merge_requests/92

   (There are a few failed tests that I have not touched at all and they failed already before I started working on the files. What do I do with these?)

I don't see any failed tests at least reported on github? Were they in the full test suite? We'll see what it says on Darwin.

@aematts let us know when you'd like a re-review, so we don't miss it.

@jhp-lanl and @Yurlungur: The PR is now ready for final review.

Can you NOT delete my branch, please. I would like to use it again for the PowerMG.

Can you NOT delete my branch, please. I would like to use it again for the PowerMG.

I changed the repository settings, the branch shouldn't be automatically deleted now.

Can you NOT delete my branch, please. I would like to use it again for the PowerMG.

I changed the repository settings, the branch shouldn't be automatically deleted now.

Just to be clear here though, the branch is only deleted from the remote repository on github/re-git. The branch remains in your local checkout, so you can continue working on the branch even after it has been merged. Whenever you push the branch again, it will then exist in the remote repo as well.

Thank you guys! @jhp-lanl , that was exactly how I did it last time but I just did not want to do it again since I will go on with PowerMG immediately.