Replies: 21 comments 7 replies
-
|
I feel like we discussed this and agreed on the following plan some time ago:
The potential problem with this plan is that
So, UI wise, it would be much easier to give the map points captions if we slightly randomized coinciding center-points (within a standard deviation equal to half the bounds of the box, say). But as @mo-nathan pointed out, this implies a level of "precision" that is fake and could be misleading. To remedy this, I proposed giving randomize-differentiated points a different color that signals that the location is approximate - I still kind of prefer this, because we will need that different color signal also for observations that do have precise GPS but have "location hidden" by the user. Mitigating consideration:
|
Beta Was this translation helpful? Give feedback.
-
|
Note my previous response edited on github - please refer to the full discussion on GitHub for the up-to-date post, rather than replying via email if possible. |
Beta Was this translation helpful? Give feedback.
-
|
I like the idea of "box" locations having a different color. It would also be reasonable in my view to have clicking on that location take the user to the set of observations in a matrix box mode if we can pull that off. It might also be really helpful to give users a way to ignore "box" locations and only plot data that has real GPS values. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Andrew. I couldn't find the previous discussion. That plan will go a long way to helping users. It's a difficult problem. |
Beta Was this translation helpful? Give feedback.
-
|
It also seems like there are bugs now. For instance, Joanne
|
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
-
|
This is as far as I've tracked it down: a raw "set" is created for Joanne's point location (GPS lat/lng, not a box). The So her point is getting lost when aggregating the point into boxes, in |
Beta Was this translation helpful? Give feedback.
-
|
Welp, Jason figured this out pretty quickly after I spent a number of hours trying to debug it by tracing the handling of the location data through the iterations of boxes. Fresh eyes!
Here is what’s going on. In Joanne's case, the occurrence map of name 5066, "Amanita muscaria subsp. flavivolvata", there is one daggone obs (392296) with the vague location “USA”.
Because we do not order locations by area (and this is not easy to do…), during the process of collapsing the many obs of "Amanita muscaria subsp. flavivolvata" into a manageable number of boxes to display on the map, the mega-location “USA" has subsumed the next several specific locations within it, obscuring them. One of these is Joanne’s observation on “Santa Cruz Island”. If you click within the box for the whole USA, including Alaska and Hawaii, you’ll find the Santa Cruz Island observation.
This is no doubt happening on any map where there are vague observation locations, not only this map.
So I can think of two things we can do:
- In the mapsets that get sent to the maps, filter out not only “Earth”, but also all locations where the box size is greater than 1º. The argument being that these are useless anyway, for the purposes of mapping. (Although a 1º x 1º area is much bigger at the poles than the equator, Jason observed that this is offset by the fact that there are very few fungi living at the poles.)
- Add a validation for observations, that forces people to associate the obs with a more specific location if they pick one bigger than this size. This may be complicated to pull off, though, because "create obs" goes through “create location” and of course it’s possible to create general locations.
|
Beta Was this translation helpful? Give feedback.
-
|
Thought: instead of trying to prevent vague observations/locations, maybe
just a warning along the lines of: "This observation/location will not
appear on maps because it is too vague. If you would like it to be included
in maps, make this location smaller than 1 degree on a side or choose a
more precise location."
On Wed, Apr 10, 2024 at 3:58 PM andrew nimmo ***@***.***>
wrote:
… Welp, Jason figured this out pretty quickly after I spent a number of
hours trying to debug it by tracing the handling of the location data
through the iterations of boxes. Fresh eyes!
Here is what’s going on. In Joanne's case, the occurrence map of name
5066, "Amanita muscaria subsp. flavivolvata", there is one daggone obs
(392296) with the vague location “USA”.
Because we do not order locations by area (and this is not easy to do…),
during the process of collapsing the many obs of "Amanita muscaria subsp.
flavivolvata" into a manageable number of boxes to display on the map, the
mega-location “USA" has subsumed the next several specific locations within
it, obscuring them. One of these is Joanne’s observation on “Santa Cruz
Island”. If you click within the box for the whole USA, including Alaska
and Hawaii, you’ll find the Santa Cruz Island observation.
This is no doubt happening on any map where there are vague observation
locations, not only this map.
So I can think of two things we can do:
In the mapsets that get sent to the maps, filter out not only “Earth”, but
also all locations where the box size is greater than 1º. The argument is
that these are useless anyway, for the purposes of mapping. (Although a 1º
x 1º area is much bigger at the poles than the equator, Jason observed that
this is offset by the fact that there are very few fungi living at the
poles.)
Add a validation for observations, that forces people to associate the obs
with a more specific location if they pick one bigger than this size. This
may be complicated to pull off, though, because "create obs" goes through
“create location” and of course it’s possible to create general locations.
> On Apr 4, 2024, at 2:34 PM, Joseph D. Cohen ***@***.***> wrote:
>
>
> It also seems like there are bugs now. For instance, Joanne
>
> Started with this Observation https://mushroomobserver.org/488916 <
https://mushroomobserver.org/488916>, of Amanita muscaria subsp.
flavivolvata, which is geolocated, and whose Location is Santa Cruz Island,
Santa Barbara Co., California, USA <
https://mushroomobserver.org/locations/5059>
> clicked Occurence Map
> But the resulting map shows no occurences on Sata Cruz Island.
> —
> Reply to this email directly, view it on GitHub <
#2088 (comment)>,
or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAO3TP23SYPRQSZYRIXOLELY3XBOFAVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TAMJUG43DA>.
> You are receiving this because you commented.
>
—
Reply to this email directly, view it on GitHub
<#2088 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAYTNNP3VVM4SSHPDOPTNFTY4WKVFAVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANZVHAZDM>
.
You are receiving this because you are subscribed to this thread.Message
ID:
<MushroomObserver/mushroom-observer/repo-discussions/2088/comments/9075826
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
I like the idea of a warning. It could also come up during editing of an obs, i guess.
… On Apr 10, 2024, at 1:30 PM, Jason Hollinger ***@***.***> wrote:
Thought: instead of trying to prevent vague observations/locations, maybe
just a warning along the lines of: "This observation/location will not
appear on maps because it is too vague. If you would like it to be included
in maps, make this location smaller than 1 degree on a side or choose a
more precise location."
On Wed, Apr 10, 2024 at 3:58 PM andrew nimmo ***@***.***>
wrote:
> Welp, Jason figured this out pretty quickly after I spent a number of
> hours trying to debug it by tracing the handling of the location data
> through the iterations of boxes. Fresh eyes!
>
> Here is what’s going on. In Joanne's case, the occurrence map of name
> 5066, "Amanita muscaria subsp. flavivolvata", there is one daggone obs
> (392296) with the vague location “USA”.
>
> Because we do not order locations by area (and this is not easy to do…),
> during the process of collapsing the many obs of "Amanita muscaria subsp.
> flavivolvata" into a manageable number of boxes to display on the map, the
> mega-location “USA" has subsumed the next several specific locations within
> it, obscuring them. One of these is Joanne’s observation on “Santa Cruz
> Island”. If you click within the box for the whole USA, including Alaska
> and Hawaii, you’ll find the Santa Cruz Island observation.
>
> This is no doubt happening on any map where there are vague observation
> locations, not only this map.
>
> So I can think of two things we can do:
>
> In the mapsets that get sent to the maps, filter out not only “Earth”, but
> also all locations where the box size is greater than 1º. The argument is
> that these are useless anyway, for the purposes of mapping. (Although a 1º
> x 1º area is much bigger at the poles than the equator, Jason observed that
> this is offset by the fact that there are very few fungi living at the
> poles.)
> Add a validation for observations, that forces people to associate the obs
> with a more specific location if they pick one bigger than this size. This
> may be complicated to pull off, though, because "create obs" goes through
> “create location” and of course it’s possible to create general locations.
>
>
> > On Apr 4, 2024, at 2:34 PM, Joseph D. Cohen ***@***.***> wrote:
> >
> >
> > It also seems like there are bugs now. For instance, Joanne
> >
> > Started with this Observation https://mushroomobserver.org/488916 <
> https://mushroomobserver.org/488916>, of Amanita muscaria subsp.
> flavivolvata, which is geolocated, and whose Location is Santa Cruz Island,
> Santa Barbara Co., California, USA <
> https://mushroomobserver.org/locations/5059>
> > clicked Occurence Map
> > But the resulting map shows no occurences on Sata Cruz Island.
> > —
> > Reply to this email directly, view it on GitHub <
> #2088 (comment)>,
> or unsubscribe <
> https://github.com/notifications/unsubscribe-auth/AAO3TP23SYPRQSZYRIXOLELY3XBOFAVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TAMJUG43DA>.
>
> > You are receiving this because you commented.
> >
>
> —
> Reply to this email directly, view it on GitHub
> <#2088 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAYTNNP3VVM4SSHPDOPTNFTY4WKVFAVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANZVHAZDM>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID:
> <MushroomObserver/mushroom-observer/repo-discussions/2088/comments/9075826
> @github.com>
>
—
Reply to this email directly, view it on GitHub <#2088 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAO3TP27ECMYIC3U7ZPFBDLY4WOPLAVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANZWGE2DK>.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
-
|
Oh yeah, could happen client-side, too, at least in some cases. If you
just select a location, it won't necessarily know if the location is vague
based on the autocomplete data (just name).
On Wed, Apr 10, 2024 at 4:42 PM andrew nimmo ***@***.***>
wrote:
… I like the idea of a warning. It could also come up during editing of an
obs, i guess.
> On Apr 10, 2024, at 1:30 PM, Jason Hollinger ***@***.***> wrote:
>
>
> Thought: instead of trying to prevent vague observations/locations,
maybe
> just a warning along the lines of: "This observation/location will not
> appear on maps because it is too vague. If you would like it to be
included
> in maps, make this location smaller than 1 degree on a side or choose a
> more precise location."
>
> On Wed, Apr 10, 2024 at 3:58 PM andrew nimmo ***@***.***>
> wrote:
>
> > Welp, Jason figured this out pretty quickly after I spent a number of
> > hours trying to debug it by tracing the handling of the location data
> > through the iterations of boxes. Fresh eyes!
> >
> > Here is what’s going on. In Joanne's case, the occurrence map of name
> > 5066, "Amanita muscaria subsp. flavivolvata", there is one daggone obs
> > (392296) with the vague location “USA”.
> >
> > Because we do not order locations by area (and this is not easy to
do…),
> > during the process of collapsing the many obs of "Amanita muscaria
subsp.
> > flavivolvata" into a manageable number of boxes to display on the map,
the
> > mega-location “USA" has subsumed the next several specific locations
within
> > it, obscuring them. One of these is Joanne’s observation on “Santa
Cruz
> > Island”. If you click within the box for the whole USA, including
Alaska
> > and Hawaii, you’ll find the Santa Cruz Island observation.
> >
> > This is no doubt happening on any map where there are vague
observation
> > locations, not only this map.
> >
> > So I can think of two things we can do:
> >
> > In the mapsets that get sent to the maps, filter out not only “Earth”,
but
> > also all locations where the box size is greater than 1º. The argument
is
> > that these are useless anyway, for the purposes of mapping. (Although
a 1º
> > x 1º area is much bigger at the poles than the equator, Jason observed
that
> > this is offset by the fact that there are very few fungi living at the
> > poles.)
> > Add a validation for observations, that forces people to associate the
obs
> > with a more specific location if they pick one bigger than this size.
This
> > may be complicated to pull off, though, because "create obs" goes
through
> > “create location” and of course it’s possible to create general
locations.
> >
> >
> > > On Apr 4, 2024, at 2:34 PM, Joseph D. Cohen ***@***.***> wrote:
> > >
> > >
> > > It also seems like there are bugs now. For instance, Joanne
> > >
> > > Started with this Observation https://mushroomobserver.org/488916 <
> > https://mushroomobserver.org/488916>, of Amanita muscaria subsp.
> > flavivolvata, which is geolocated, and whose Location is Santa Cruz
Island,
> > Santa Barbara Co., California, USA <
> > https://mushroomobserver.org/locations/5059>
> > > clicked Occurence Map
> > > But the resulting map shows no occurences on Sata Cruz Island.
> > > —
> > > Reply to this email directly, view it on GitHub <
> >
#2088 (comment)>,
> > or unsubscribe <
> >
https://github.com/notifications/unsubscribe-auth/AAO3TP23SYPRQSZYRIXOLELY3XBOFAVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TAMJUG43DA>.
> >
> > > You are receiving this because you commented.
> > >
> >
> > —
> > Reply to this email directly, view it on GitHub
> > <
#2088 (comment)>,
> > or unsubscribe
> > <
https://github.com/notifications/unsubscribe-auth/AAYTNNP3VVM4SSHPDOPTNFTY4WKVFAVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANZVHAZDM>
> > .
> > You are receiving this because you are subscribed to this
thread.Message
> > ID:
> >
<MushroomObserver/mushroom-observer/repo-discussions/2088/comments/9075826
> > @github.com>
> >
> —
> Reply to this email directly, view it on GitHub <
#2088 (comment)>,
or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAO3TP27ECMYIC3U7ZPFBDLY4WOPLAVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANZWGE2DK>.
> You are receiving this because you commented.
>
—
Reply to this email directly, view it on GitHub
<#2088 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAYTNNNVFZR2SPSOMW7IV3TY4WP2XAVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANZWGI2DM>
.
You are receiving this because you commented.Message ID:
<MushroomObserver/mushroom-observer/repo-discussions/2088/comments/9076246
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
How about printing a warning (not a flash) in the show obs view at all times, if the location is nonspecific, that will explain the change in "policy"? We could vary the verbiage if it's the current user's own obs. Public warning: I'm thinking it might spur people to clean up their own data, because it would appear even when reviewing old obs. |
Beta Was this translation helpful? Give feedback.
-
|
IMO
1. It's okay to ask users to pick a different, more precise Location.
2. I'm concerned about the side-effects of modifying a Location. It may
- Put the lat/lon of other Observations outside the bounding box of the
modified Location.
- May otherwise surprise other Users who pick the modified Location for new
Observations.
- May induce users to narrow the bounding box so that it doesn't fit the
natural meaning of the Location.name.
3. The warning should include at least one example.
…On Wed, Apr 10, 2024 at 4:22 PM andrew nimmo ***@***.***> wrote:
How about printing a warning (not a flash) in the show obs view at all
times, if the location is nonspecific, that will explain the change in
"policy"? We could vary the verbiage if it's the current user's own obs.
Public warning:
This observation's location will not appear on maps because it is too
vague.
Addendum to obs owner:
If you would like it to be included in maps, make this location smaller
than 1 degree on a side, or choose a more precise location.
I'm thinking it might spur people to clean up their own data, because it
would appear even when reviewing old obs.
—
Reply to this email directly, view it on GitHub
<#2088 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALDFE3APIGKULQTENAF2DY4XCT7AVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANZXGI2TO>
.
You are receiving this because you authored the thread.Message ID:
<MushroomObserver/mushroom-observer/repo-discussions/2088/comments/9077257
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
Joe raises a good point about the verbage "make this location smaller".
People are already confused about how to edit an observation's location,
let's not further encourage people to modify locations!
But it seems like a win all around to gently encourage users to provide
useful location data.
On Wed, Apr 10, 2024 at 8:55 PM Joseph D. Cohen ***@***.***>
wrote:
… IMO
1. It's okay to ask users to pick a different, more precise Location.
2. I'm concerned about the side-effects of modifying a Location. It may
- Put the lat/lon of other Observations outside the bounding box of the
modified Location.
- May otherwise surprise other Users who pick the modified Location for
new
Observations.
- May induce users to narrow the bounding box so that it doesn't fit the
natural meaning of the Location.name.
3. The warning should include at least one example.
On Wed, Apr 10, 2024 at 4:22 PM andrew nimmo ***@***.***>
wrote:
> How about printing a warning (not a flash) in the show obs view at all
> times, if the location is nonspecific, that will explain the change in
> "policy"? We could vary the verbiage if it's the current user's own obs.
>
> Public warning:
> This observation's location will not appear on maps because it is too
> vague.
> Addendum to obs owner:
> If you would like it to be included in maps, make this location smaller
> than 1 degree on a side, or choose a more precise location.
>
> I'm thinking it might spur people to clean up their own data, because it
> would appear even when reviewing old obs.
>
> —
> Reply to this email directly, view it on GitHub
> <
#2088 (comment)>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AAALDFE3APIGKULQTENAF2DY4XCT7AVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANZXGI2TO>
> .
> You are receiving this because you authored the thread.Message ID:
>
<MushroomObserver/mushroom-observer/repo-discussions/2088/comments/9077257
> @github.com>
>
—
Reply to this email directly, view it on GitHub
<#2088 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAYTNNPF73NJPOYZRPTKHOTY4XNOXAVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANZXGY4DC>
.
You are receiving this because you commented.Message ID:
<MushroomObserver/mushroom-observer/repo-discussions/2088/comments/9077681
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
Is everybody ok with the verbiage I put in the PR? |
Beta Was this translation helpful? Give feedback.
-
|
Works for me.
…On Thu, Apr 11, 2024 at 3:07 PM andrew nimmo ***@***.***> wrote:
Is everybody ok with the verbiage I put in the PR?
—
Reply to this email directly, view it on GitHub
<#2088 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAYTNNPBNKNMSSLRPOPEYQLY43NNNAVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TAOBYGA3DM>
.
You are receiving this because you commented.Message ID:
<MushroomObserver/mushroom-observer/repo-discussions/2088/comments/9088066
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
Proposal for maps of single observations: Start to favor GPS point data over LocationsPR #2092 makes a change in display for "Map of Observation" where the obs has "point" data: it assumes that the GPS info is more reliable than the associated Location record. If the point disagrees with the location, it displays that point, rather than defaulting to the Location bounding box, as currently. I'd like to hear how people feel about this change. BackgroundCurrently, when people create an observation:
Even though GPS is not 100% reliable either, it's the GPS point that should probably be considered definitive, not the Location the observation is associated with. I feel like the way we handle all this currently adds unnecessary confusion and effort for users. Also, the tight check for So this PR also loosens the requirement for It's GPS data we want to encourage people to provide, not "better" entries in the Location table, in my opinion. |
Beta Was this translation helpful? Give feedback.
-
What we show when GPS and Location diverge:Observation 419427 is part of a group of observations by a single user that were all associated with one Location (15788, Sage Hen Mountain, Idaho), possibly because it kept being autofilled as their "last location used" in the Create Obs form. This observation also has GPS point data, and according to that, it seems to have been found ~50mi from the location assigned to it. Currently on main, it maps the location here:
The PR branch shows the GPS location:
Distance between these places is pretty great:
|
Beta Was this translation helpful? Give feedback.
-
|
(Discussion has been edited for clarity) |
Beta Was this translation helpful? Give feedback.
-
|
As Terri points out, occurrence maps are currently box locations only, to avoid the mixed “pins and boxes” display people were complaining about.
These are our choices for occurrence maps: show boxes and only boxes, or show pins and only pins, with Google’s clustering. I believe people are in favor of the switch to pins, but please do speak up if you foresee problems with this approach.
|
Beta Was this translation helpful? Give feedback.
-
|
Generally I like the direction of making GPS coordinates take priority and doing something reasonable for observations that we only have location information for. However, note that hidden observations need to be handled correctly. For the new "hidden locations" I essentially rounded the GPS coordinates for the location to the nearest 0.1 degrees (round 6 miles in most reasonable places in the world). There's an interesting case of what to do if you have a hidden observation with GPS in a hidden location that the user does not have permission to see. I think the right thing to do in this case is to use the hidden location. I think it would be reasonable to not show the precise location even if the person doing has permission to see the precise location. |
Beta Was this translation helpful? Give feedback.
-
|
That sounds about right. But I want to be sure everyone realizes this is an either-or choice, and is on board with it, before i put a lot of work into it. As far as I know, we cannot have a mix of boxes and points on a map with Google point clustering.This means NO MORE BOXES on occurrence maps. If we switch to automatic point clustering, for observations without GPS, or observations with hidden GPS, or hidden Locations, or just Locations, we have to make the location boil down to a point. We can give it a different color if it's a Location center point, and a third color if it's hidden. But it's got to be represented by a point, and that may confuse some people. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the reminder of where we are, where we're going, and prohibition
on mixing boxes and points.
I'm good with no boxes.
I'm good with different color pins for (1) obs with public lat/lon, (2) all
other obs. IMO it gets too confusing to have to more colors, but I'm also
okay with that if you to go that way.
Even better (but maybe something for another PR) would be different
style pins, such as (1) regular pin for obs with public gps, (2) circle for
obs with obscured gps or location, (3) quadrilaterial pin for obs with only
public location.
See
https://cloudfresh.com/en/blog/reimagine-your-mapping-experience-with-google-maps-advanced-markers/
,
https://developers.google.com/maps/documentation/javascript/reference/advanced-markers
-Joe
…On Wed, May 8, 2024 at 3:54 PM andrew nimmo ***@***.***> wrote:
That sounds about right. But I want to be sure everyone realizes this is
an *either-or choice*, and is on board with it, before i put a lot of
work into it.
As far as I know, we cannot have a mix of boxes and points on a map with
Google point clustering.
This means NO MORE BOXES on occurrence maps. If we switch to automatic
point clustering, for observations without GPS, or observations with hidden
GPS, or hidden Locations, or just Locations, we have to make the location
boil down to a point. We can give it a different color if it's a Location
center point, and a third color if it's hidden. But it's got to be
represented by a point, and that may confuse some people.
—
Reply to this email directly, view it on GitHub
<#2088 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALDFFI7VBPHFOTVFDZYL3ZBKUI3AVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGNRRGIZDK>
.
You are receiving this because you authored the thread.Message ID:
<MushroomObserver/mushroom-observer/repo-discussions/2088/comments/9361225
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
I'm perfectly happy getting rid of boxes. They were a short cut I took a long time ago to avoid doing real polygons and I doubt anyone is really attached to them. We may get some grumbles from people who don't want their cheese moved, but I would be interested in hearing from them what they actually like about it. Little MO mushroom pins would be cool. But i wouldn't be in favor of the generic Mario-esque unicode mushroom (🍄). However, I'd also be perfectly happy with colored pins or essentially boxes and circles as Joe suggests. INat's square heat map approach is also nice, but probably a lot more work. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW, I'm also fine with removing boxes altogether. Centerpoint of most
box locations is just fine. Locations too vague to include on the map are
omitted (as they already are, I think).
…On Wed, May 8, 2024 at 7:39 PM Nathan Wilson ***@***.***> wrote:
I'm perfectly happy getting rid of boxes. They were a short cut I took a
long time ago to avoid doing real polygons and I doubt anyone is really
attached to them. We may get some grumbles from people who don't want their
cheese moved, but I would be interested in hearing from them what they
actually like about it.
Little MO mushroom pins would be cool. But i wouldn't be in favor of the
generic Mario-esque unicode mushroom (🍄). However, I'd also be perfectly
happy with colored pins or essentially boxes and circles as Joe suggests.
INat's square heat map approach is also nice, but probably a lot more work.
—
Reply to this email directly, view it on GitHub
<#2088 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAYTNNJHC5HCL52WE2NXFS3ZBKZSTAVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGNRRGQ3DM>
.
You are receiving this because you commented.Message ID:
<MushroomObserver/mushroom-observer/repo-discussions/2088/comments/9361466
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
|
Re pin shape: I like the narrowest possible (vs little MO mushroom pins) because they obscure less of the map (and other pins). |
Beta Was this translation helpful? Give feedback.
-
|
We may get a choice on pins, but i'm not sure we get a choice on cluster markers. |
Beta Was this translation helpful? Give feedback.
-
|
Here are some "pins" (just dots really) that I created for my own private
herbarium database system. A bit boring, but they may meet Joe's
preferences?
…On Wed, May 8, 2024 at 10:25 PM Joseph D. Cohen ***@***.***> wrote:
Re pin shape: I like the narrowest possible (vs little MO mushroom pins)
because they obscure less of the map (and other pins).
—
Reply to this email directly, view it on GitHub
<#2088 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAYTNNKMDXTGPCSVTW2JDNDZBLNBDAVCNFSM6AAAAABFX6QIACVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGNRSGM3TA>
.
You are receiving this because you commented.Message ID:
<MushroomObserver/mushroom-observer/repo-discussions/2088/comments/9362370
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
What can do to generate comprehensible maps?
I'm attaching an email chain with power user Joanne Schwartz, who reports that her troubles with maps started recently.
She wanted to see a map of her Observations on Santa Cruz Island.
IMO the maps we generated are incomprehensible.
Uploading Joanne maps question.pdf…
Beta Was this translation helpful? Give feedback.
All reactions