Quirks with observation fields and hash/pound/number signs (#)

[pisum]

There are some quirks when using hash/pound/number signs (#) with observation fields:

Quirk #1

In the Explore page, you can’t search for fields that begin with #. For example, if you open the observation detail page for an observation that uses the observation field # of antler points, you should be able to go to the observation field section, and click on the observation field, and then choose to find either observations with the same observation field or the same observation field + value:

If you choose Observations with this field, you get directed a bad URL (since the # is not encoded properly in the URL): https://www.inaturalist.org/observations?verifiable=any&place_id=any&field:#%20of%20antler%20points.

(Quirk #1b)

But even if you attempt to fix the URL by replacing # with %23, this new URL still doesn’t find the right set of observations: https://www.inaturalist.org/observations?verifiable=any&place_id=any&field:%23%20of%20antler%20points

Compare that with what happens in the case of an observation field that ends with #, such as Vial #. If you start on an observation that uses that observation field and choose Observations with this field, you are still directed to an improperly encoded URL: https://www.inaturalist.org/observations?verifiable=any&place_id=any&field:Vial%20#

However, you can fix the encoding, and the URL will return the expected results: https://www.inaturalist.org/observations?verifiable=any&place_id=any&field:Vial%20%23

Quirk #2

In the Observation detail page, if you input a text value for an observation field, and the text value begins with #, then you get more strangeness.

For example, when I input this:

I end up with this:

Effectively, it looks like the page is interpreting text that begins with # as markdown, thereby displaying the text without the leading # and formatting the rest of the text as if h1.

Quirk #3

Now, staying with the same example from Quirk #2, when I choose the option to find Observations with the same field and value, I am directed to this URL: https://www.inaturalist.org/observations?verifiable=any&place_id=any&field:Text=#%20of%20birds%20is%20approximate.

Rather than returning just the observation that has that specific text value, the URL returns any observation that uses this field (since I assume that everything after the # in the URL is treated as a fragment, or a reference to a specific named section of the page). A URL with the proper encoding of the # does give the expected results though:
https://www.inaturalist.org/observations?place_id=any&field:Text=%23%20of%20birds%20is%20approximate&verifiable=any

[kaipatiki_naturewatc]

This bug, if it a bug, or hidden quirk, caused me some grief a couple of years ago when I created and used several fields or values, or both, (I forget which), using the number sign.

I learned not to use the number sign in fields or values, but would hve preferred that the website did not allow me to use the symbol # in creating the field.

[exonie]

This is similar to Link not working in observation field. I ran into the same problem with a comma character in my URL inside an observation field.

I don’t know why the other bug report was closed since manual entering of URL encoded characters is more like a workaround. The user should not be required to do this or even to know about this. The platform should encode/decode the characters when needed.

[pisum]

you’re right. it does look like Quirks #1(/b) and #3 from the original post here apply to other characters besides # which need to be encoded in the URL.

i guess it doesn’t matter if the other thread is closed since this one exists and is still open. if the problems noted here are fixed (the right way), that should fix the problems noted in the other thread.