Display Contacts on Maps

[tacruc]

Planing of showing contacts on the map.

ToDo:

• Caching Table for addresses to Cordinates (Address string), Lat, Lng, timelookedup
• When to look up the results, We should query less then one time per second, so one demand is not possible => should be done in the backend in advanced, to not hit the one request per second limitation
• Extend the navigation to show "suggestions for contacts"
• Api call for contactSuggestions
• phrase coordinat form vCard in backend and frontend
• make contact preview nice
• Delete Geo attribute from vCard
• Set geo attibute according to vCard version, in vCard v4 it should be an geo url.
• Check permission when setting Geo Attribute

Possible interesting vCard Attibutes

• ADR
  • Can be multiple, I guess all are interesting
• GEO
  • Different formates in v2,3 and v4

Problems

• it's currently possible to place a contact (edit its coordinates) even if it's from an address book shared with me with readonly permissions.

[julien-nc]

Yep, I think vCard GEO attribute should be used in priority if it's there. Then if there are multiple addresses, i guess one could be used arbitrarily.

There's more, considering we have an address, there might be multiple search result. We can reasonably assume it's ok to take the first result.

Photo metadata are generated by the file hook. How could we proceed for Contacts? Is there a hook when a contact is created/updated? Or should we access contact database on each Maps page load? It would be smart to make the address search just once and store the result coordinates in Maps DB 😄.

A lot to think about.

[tacruc]

Well why would it be bedder to have it in extra table? There are hooks on carddav. But I think I would just read it from the db or an api.

[julien-nc]

So maps DB could act like a sort of cache: first time a contact is loaded from contact DB, data is generated and stored, next time it's just retrieved from Maps DB.

Is there a way to know if a contact was modified since a precise date?

[julien-nc]

Well why would it be bedder to have it in extra table?

To store potential coordinates resulting from geocoder search and avoid calling nominatim each time we load the contacts.

[tacruc]

We cloud maybe use
public OCP\Contacts\IManager::search($pattern, $searchProperties=array(), $options=array())

[julien-nc]

Nice to see the new contact controller.

About the contact base64 picture: no problem, <img src="BASE64_STRING"/> works fine.

About the geo information, do you mean it's supported by vCard v4 and not by v3?
Which version of vCard is supported/provided by Nextcloud API and contact storage?

You're right about not needing to store anything in Maps DB. If there is a geo field already there, we should use it.

About guessing the coordinates, my main concern is to be able to avoid doing the geocoder request multiple times for a contact. I mean, let's say we don't store the guessed coordinates until they are confirmed or edited by the user, it means we have to guess it again next time Maps page is loaded.

If we store them in the contact (server side), we need to remember that they have just been guessed and they are not definitive. If we don't store them in the contact, we could store them in Maps DB.

I like the idea of displaying contacts with guessed position with a different color to make it clear to the user that it might be wrong and that it can/should be edited.

Guessing picture coordinates seems trickier. Let's wait until the "device" part is implemented to think about that.

[tacruc]

About the geo information, do you mean it's supported by vCard v4 and not by v3?
Which version of vCard is supported/provided by Nextcloud API and contact storage?

https://en.wikipedia.org/wiki/VCard#Properties
The encoding is different between v3 and v4. Nextcloud supports both, and it is easy to adapt the filter to support v3, it is just not done jet.

About guessing the coordinates, my main concern is to be able to avoid doing the geocoder request multiple times for a contact. I mean, let's say we don't store the guessed coordinates until they are confirmed or edited by the user, it means we have to guess it again next time Maps page is loaded.

We cloud make a cacheing table in the maps app. This cloud be used for any geoinformation, request.

If we store them in the contact (server side), we need to remember that they have just been guessed and they are not definitive. If we don't store them in the contact, we could store them in Maps DB.

If we do it the right way, (what we should do) it changes the vCard and syncs to all devices. I wound't like it for a guessed not confirmed information. So I would prefer the caching table.

I like the idea of displaying contacts with guessed position with a different color to make it clear to the user that it might be wrong and that it can/should be edited.

what do you think about black and white and maybe 50% transparent?

Guessing picture coordinates seems trickier. Let's wait until the "device" part is implemented to think about that.

The Device is needed for that, but I think the logic is not to difficult I would do it than.

[tacruc]

I have thought again about the showing the address on the map.
The lookup of the coordinates should be done in the back end.
Therefore I would register Hooks on vCard write access events. A PR for this is created with nextcloud/server#14973
The new addresses cloud be saved in a table and with each cronjob we cloud ask for x new address locations.

[julien-nc]

Yep, a vCard hook would be perfect to avoid overloading the server!

A cronjob sounds good but there still is a "problem" just after app install, when using Maps before the cronjob was triggered, there's not going to be any guessed contact coordinates yet.

BTW, do you know how to remove/unset a contact vCard property with NC API? I quickly gave up after failing because setting it to a null value does not work and API doc didn't help.

[tacruc]

The will be a time delay between the contact is added and it is visible on the map. It will be
TimeToNextCronjob + AddressesToLookup/lookupsPerCronjob*IntervalCronjob

But I guess we will not get bedder with that external provider.
The problem is that the PR for the Hooks is not merged, so it will be earliest available in NC17.

BTW, do you know how to remove/unset a contact vCard property with NC API? I quickly gave up after failing because setting it to a null value does not work and API doc didn't help.

no idea

[julien-nc]

The will be a time delay between the contact is added and it is visible on the map.

If there is a contact hook, there won't be any delay 😄.
If there's no contact hook, the delay is acceptable IMHO.

no idea

So the "contact geo field reset" is sleeping in the code until we sort it out.

[tacruc]

So you would do the lookup directly on the vCard create event? But wouldn't that mean that initializing and uploading 200 contacts to the server will create 200 requests to the provider at once? Shouln't there be some delay mechanism?
I was thinking on adding them to a list table on the hook, and doing the lookup by the cronjob, to catch the initial upload of an hole addressbook.