Hi, thanks for your reply :) Le lundi 22 février 2010, à 00:00:29 +0200, Jussi a écrit : > > The use cases for this include > * a panel applet that shows the current location (from master) and a > way to correct it: a text entry and/or a map widget. > * twitter client that uses geoclue but lets user correct the location > > The basic needs are: > 1. We want to let users define their location manually, possibly from > several applications > 2. This manual input must be able to override other sources > (so users can correct wrong location info) > 3. we should "save" this manual info for later use > (based on MAC address, possibly other things) > 4. saved info must be easily modified/erased
I can see two other needs: * have a default position, which does not depend on the gateway or anything else. Ie: user wants its software to believe he is in position XY no matter where he really is. * set an accuracy: so user can tell: I'm not further than xx meters or kilometers from position XY. I'm thinking here about web geolocation where websites can ask for location. For privacy reason, user may wish to give a wrong position or an inaccurate one. > Originally I only implemented Address interface in manual & > localnet, but I do agree Position should be covered as well: > clicking a location on a map is obviously a use case for that. yes :) > That said, I'm not at all sure the current implementation in > 'manual' & 'localnet' is good: They were quite ad-hoc -- this is the > reason there's no real documented API for them... It might make > sense to evaluate the design now and define a proper API if you want > to do some work on this. > > > Some questions/ideas: > > * Do we need separate 'manual' and 'localnet' providers? I'm > starting to think we don't: the "valid_for" property in manual > didn't turn out to be useful, and if we remove that the > functionality is very much covered by localnet already... The > provider name could be better, like "user-set" or something. I hadn't look at the manual provider before. But yes, it looks quite similar to localnet. > * User provided information should probably trump even more > "accurate" other providers, when master selects current provider. I > guess this could be done with e.g. a flag in .provider-file? then, why have one more accuracy level, and set user-set provider to that level. Then, it will be preferred over current providers. Also, from documentation, it appears, horizontal_accuracy and vertical_accuracy are defined only if accuracy level is not GEOCLUE_ACCURACY_LEVEL_DETAILED. So, in order to meet the use cases I describe earlier localnet needs to have its accuracy level increased anyway. > > * Currently localnet works based on MAC address. Are there other > things we could use? We should also probably start looking at the > type of the network we're on: I assume this method is not a very > good one on a GSM data connection for example. random thought: may be use public ip which could be fetched from sites like showmyip.com or other similar ones. I don't known if that idea is a good one though. > * When defining the API for setting a manual position, make sure > it's possible to remove the manual position as well. yes, it's really important. > One related note: I think a "ReverseGeocode.freeform_to_address()" > would be very useful addition in combination with localnet. Think > about the Twitter client example: > * user inputs something like "Helsinki" > * the app uses freeform_to_address() and then saves the received > location with localnet I'm not sure I understand. Do you mean localnet should implement org.freedesktop.Geoclue.ReverseGeocode ? Or should that method be implemented by geoclue-geonames provider ? I'll try to work on that project at the end of the week regards arno
signature.asc
Description: Digital signature
_______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
