Re: Current Location

Ricardo_Gonzale · 07-23-2019 06:57 PM

Alright… This is about showing the current location on the map.
I’ve been trying to solve this for a few days now in a replicated prototype of my live version.
I have a data table that feeds into a slice.
This slice is the data set for the map view.
There is currently one location column, “location,” that shows all of the pins on the map that match the condition of the slice.

So, normally, about 20 different pins show on the map.
Additionally, a “View Map (Location)” button that shows up on the map, on the bottom right.
When this button is clicked, a bouncing red pin shows that, when moved, feeds into a form, that will eventually populate more pins.

When this button is clicked inline, it shows the current pin’s zoomed location on the map.
This “View Map (Location)” button on the map only shows if the data set is editable and if the main source of the map view is “Location.”
This button is necessary.

Now, the staff has suggested creating a virtual column with the “Here()” formula and use this instead of the “Location” column for the map view.

There are several issues.

If the “Location” column is replaced with “Here()” virtual column, the “View Map (Location)” system-generated action disappears. This action cannot be replicated. Even if I create the exact copy, it does not appear on the map the same way as it did before.
If the “Here()” virtual column is toggled to show, the current pins are repopulated as plain green pins in a close cluster. The pins are not in their designated locations and it looks very wrong.
If the “Here()” virtual column is toggled to not-show, the weird green pins don’t show, but none of the other pins from “Location” show either.
If “Here()” is the main column and “Location” is the secondary column, the “View Map (Location)” action is still not shown, the map is zoomed out just like it was when it was only “Location” as the main column, and the purpose of “Here()” virtual column is pointless.
Same if “Location” is the main column and “Here()” virtual column is secondary, just the “View Map (Location)” action is viewable, but the start view of the map is STILL not the user’s current location.
If there is no “Here()” virtual column, the initial value of “Here()” for the “Location” column doesn’t affect anything. The map still begins showing all the pins on the map instead of the user’s current location.
If the app formula for the “Location” column is edited in ANY way, the “View Map (Location)” action disappears.

…
I’ve tried many, many things.
Here is my suggested solution…

Please stop giving advice to add a virtual column with the “Here()” formula, it only works if there are no other pins on the map.
Currently, the “Add” and “View Map (Location)” actions, system-generated, seem to be the only ones that are allowed to show on the bottom right of the map view. We should have the option to add our own actions to this place as well.
The action I suggest is some sort of LINKTOVIEW or CONCATENATE button that people can click (inline, prominent, overlay, and map bottom right) that will take a person to their current location.
When completing a form, in the location input, there’s a bouncing red pin and in the upper-right of the small map box, there’s a small map pin… This map pin, when clicked, takes a person directly to their current location… Why can’t this type of button be recreated anywhere else in the app?
The DEFAULT view of a map view should NOT be the view of all the pins. This means that if pins exist in Africa and Japan, the CURRENT default view shows both Japan and Africa at once. This is very annoying for people who only care about dropping a pin in their current location (20~50km) map range.

It’s either a new required & necessary feature or somehow use the current formulas to link directly to a person’s current view. I know a feature might take a few days or so to roll out, but in the meantime, would really appreciate the correct formula to link

Actions should be allowed to be shown in the navigation bar or menu as well.
So we can have the option of replacing the map view in the navigation bar and replacing it with an action that leads to a map view starting at the user’s current location.

This is such a complicated issue, but I really hope to receive a solution soon.
Thank you.

Ricardo_Gonzale

Alright, I’ve created a viable & smooth solution with what we have now.
Based on the principles of geofencing.
What’s needed:
・Ability to change USERSETTINGS() in the Data category, User Settings is right of the Slices tab.

Create a virtual column called “NEARBY” or whatever you want to call it, the formula will be ROUND(DISTANCE(HERE(), [Location])), type “Number” … [Location] is the name of my LatLong column that feeds into my map view.
Go to User Settings and toggle Options Heading to show, then edit the name of the next option to “DISTANCE” or whatever you want, make it Enum, Number type, and add some options… 20, 50, 100, 1000, 5000… Or whatever you want.
Go to your slice, if it’s already [some column] = “this value” just change it to AND([some column] = “this value”, [NEARBY] < USERSETTINGS(DISTANCE)) … IGNORE THE ERROR
Save & Verify.
Go to the UX category, go to the Options tab, under General, select User Settings as the starting view.
Go to the UX category, go to Views tab, you will see the Settings view, change the finish view to your map view.

Remember, your slice needs to feed into your map view.
20km radius from the user’s current location is close enough a solution to the HERE() problem I mentioned above.

More filters can be created & selected from the User Settings and placed into the Slice.
For my app, I localize the language according to the user, which adds another level of complication.
In the future, I plan to add several other languages so this app can become global.
Thank you for providing such an easy to use and editable platform for us and my NPO.

This is a really useful trick that I hope the staff can pin when you replicate & verify it.
@Adam please take a look!

Mike_T

This is a good solution and beats trying to geofence using 4 coordinates. However, I have a little bit of a wrinkle/challenge I would like to throw out there.
If I have a table full of locations with latlong (and I’m talking 200,000 locations), how can I identify which location is closest using HERE(). Essentially I want to confirm that the USER is nearby a location (or inside) when they submit the form. Or even preselect a small list of locations using HERE() from the larger list.

The process would go…

user enters a location
opens app & form
enters data
submits form
report shows the user was closest to “X” location from the list when submitting the form

Thoughts?

Bellave_Jayaram

One way could be to add 4 columns for each location - LatNearMin, LatNearMax, LongNearMin and LongNearMax and filter location based on lat and long of HERE().

Steve

You could try:

TOP(
  ORDERBY(
    locations-table[key-column],
    DISTANCE([latlong-column], HERE()),
      FALSE
  ),
  5
)

Replace locations-table with the name of the “table full of locations”; key-column with the name of the key column of that table; and latlong-column with the name of the column in that table with the locations’ LatLong values.
DISTANCE([latlong-column], HERE()) computes the distance between the user’s current location (HERE()) and the location described by a given row.
ORDERBY(locations-table[key-column], ...) orders the rows of the locations table by distance from here (per (2)) in ascending (closest to furthest) order (per FALSE).
TOP(..., 5) gives the first 5 rows from the list generated by (3), which should be the 5 closest.

See also:

This describes DISTANCE():

Bellave_Jayaram

This is gonna take some time for 200000 locations but hopefully not too prohibitive.

MultiTech

Man… 200,000 rows. The table better be sparse - like… only the lat and long, maybe an ID. 200k rows is a lot for a mobile device, or even a PC, to handle. Hosting this on a SQL will help; any cloud-based spreadsheet will run REEEEAAAAALLLLLYYY slow.

I’ve found that 30k records is the trouble point for Google sheets;

your app will be lightning fast under 10k records;
10k - 20k and things start to slow in certain areas, which you can usually refine and smooth out these choke-points;
but when you get to 20k things really start to bog; you’ve got to get smart on what you’re calculating, how you’re calculating it, etc.
30k+ and you need to migrate to a SQL server; this helps bring things back down to the performance your users will remember around 15k-25k records (not that they would know this count), otherwise performance-lag will really start to show.

One of my long-time clients is a tele-health company; we’ve been fighting the good-fight on data-bloat for the past two years. We collect data points like weights, med tracking, etc. and you can see how records would stack up quickly.

On one respect, you want all the data there for the best possible analysis; but on the other, you can’t include everything because then the app wouldn’t be workable. We’ve had to come up with informed data-schema updates, where we took into consideration HOW people were working with the app and made changes to how we were storing certain parts.

You might need to consider ways of splitting your location table into smaller ones (by state, region, etc.), then make use of the partitioning feature in Tables:

Mike_T

Thank you for the heads up on data bloat. You are absolutely right that this would bog down any machine. I can and will breakup the reference coordinates by state using the partitioning option. Thanks again for the reply. When/if I get it up and running I’ll circle back.

consultation_co

Hi Ricardo,

thanks for the proper advice and I tried Here() and what you said is perfectly correct. So I decided to try your way. Now I am stuck at step 3. I am confused with “if it’s already [some column] = “this value” just change it to AND([some column] = “this value”, [NEARBY] < USERSETTINGS(DISTANCE)) … IGNORE THE ERROR”. I have recorded a video to show what I have done and not done. Please take a look and advice next.

Fabian_Weller

Hi @Ricardo_Gonzalez Here is a workaround: