First Last Prev Next    No search results available
Bug 2962 - (int-116910) Not able to open Maps application with contacts location as a search string
(int-116910)
: Not able to open Maps application with contacts location as a search string
Status: RESOLVED FIXED
Product: Contacts
General
: 5.0/(2.2009.51-1)
: All Linux
: High major with 36 votes (vote)
: 5.0/(10.2010.19-1)
Assigned To: unassigned
: contacts-bugs
:
:
: 1979 3269
:
  Show dependency tree
 
Reported: 2008-02-19 21:59 UTC by David Hagood
Modified: 2010-06-07 13:55 UTC (History)
8 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)


Note

You need to log in before you can comment on or make changes to this bug.

Description David Hagood (reporter) 2008-02-19 21:59:05 UTC 
Use case:
User has multiple contacts in the Evolution database (Contacts app). User
wishes to associate one or more physical locations with a contact (e.g. home,
business), and have those addresses show up in the Map application as points of
interest.

This requires both the addition of all the fields EDS supports (bug #1979) as
well as some way to tie that into the Wayfinder application.

Even better would be if one device could notify another about its location
(e.g. by using Jabber over an IM system).
Comment 1 Joel Dimbernat 2008-08-04 11:49:53 UTC 
*** This bug has been confirmed by popular vote. ***
Comment 2 Javier Jardón 2009-03-29 22:28:02 UTC 
Still valid in 4.1.3 (5.2008.43-7) maemo release
Comment 3 Andre Klapper maemo.org 2009-09-03 13:32:42 UTC 
This seems more like a Contacts code issue than a Maps issue currently. Moving.
Still valid in latest Fremantle.
Comment 4 Andre Klapper maemo.org 2009-09-03 13:33:41 UTC 
*** Bug 5080 has been marked as a duplicate of this bug. ***
Comment 5 Andrew Flegg maemo.org 2009-09-03 15:18:01 UTC 
It's worth noting that in Fremantle, the Contacts app *does* support all these
extra fields; it's just that "Address" isn't as integrated as "Birthday",
"Email", "SMS", "Web page", "Phone" etc.

See description on #5080.
Comment 6 Mikhail Zabaluev nokia 2009-09-04 16:54:38 UTC 
Is there a standard URI scheme for geographical locations? We could think about
contacts opening a URL handler which could be a third-party application as
well.
Comment 7 Andrew Flegg maemo.org 2009-09-04 16:59:41 UTC 
(In reply to comment #6)
> Is there a standard URI scheme for geographical locations? We could think about
> contacts opening a URL handler which could be a third-party application as
> well.

From http://geouri.org/, I found
http://tools.ietf.org/html/draft-mayrhofer-geopriv-geo-uri-01 - however this is
limited to longitude, lattitude and (optionally) altitude. So it'd still need
to use the existing Maps to handle the translation of street, city, zip code &
country to those coords.

Perhaps an "open address" D-Bus service would be sufficient, also keeps it open
for third party implementations.
Comment 8 Andre Klapper maemo.org 2009-09-04 17:13:53 UTC 
Quoting pierlux here:

<pierlux> you should create somewhat a standard, here are some guide lines:
<pierlux> after I searched for how addresses are displayed in the world, the
only thing we can assume is that we don't agree on the information position:
<pierlux> Japan likes the postal code first, North ameica last, Europe before
the city name
<pierlux> it might be preferable to pass each fields separately
Comment 9 Mikhail Zabaluev nokia 2009-09-04 17:23:24 UTC 
(In reply to comment #7)
> Perhaps an "open address" D-Bus service would be sufficient, also keeps it open
> for third party implementations.

That's definitely a taller order. Maybe Tracker and its ontologically-organized
data model could help us here, but it's not for Fremantle.
Comment 10 Andre Klapper maemo.org 2009-10-04 23:05:02 UTC 
*** Bug 3090 has been marked as a duplicate of this bug. ***
Comment 11 Andre Klapper maemo.org 2009-12-03 11:57:26 UTC 
*** Bug 6520 has been marked as a duplicate of this bug. ***
Comment 12 Quim Gil nokia 2009-12-07 09:43:06 UTC 
See
http://maemo.org/community/brainstorm/view/maps-contacts-calendar_integration/
Comment 13 Quim Gil nokia 2009-12-15 08:06:41 UTC 
Aligning this report with the internal one in bugzilla.

At least the aim is to provide this in Fremantle.
Comment 14 Johannes Siipola 2009-12-25 16:50:06 UTC 
*** Bug 7311 has been marked as a duplicate of this bug. ***
Comment 15 Andre Klapper maemo.org 2010-02-09 19:57:55 UTC 
This has been fixed in package
libosso-abook 4.20100129.2+0m5
which is part of the internal build version
10.2010.05-10
(Note: 2009/2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Comment 16 Andre Klapper maemo.org 2010-03-15 20:53:05 UTC 
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).
Comment 17 Alex Smirnoff 2010-06-06 04:14:23 UTC 
(In reply to comment #16)
> Setting explicit PR1.2 milestone (so it's clearer in which public release the
> fix will be available to users).
> 
> Sorry for the bugmail noise (you can filter on this message).
> 

..and it it does not work in PR1.2. 
Map application is called, but it shows the same location in the city for all
contacts. Perhaps i should open a separate bug for that?
Comment 18 Andre Klapper maemo.org 2010-06-07 13:55:49 UTC 
(In reply to comment #17)
> Perhaps i should open a separate bug for that?

See bug 10499.
First Last Prev Next    No search results available