[OSM-dev] Gsoc 2010 project idea

[amit singh]

2010/4/10 Jean-Guilhem Cailton <jgc at arkemie.com>

> amit singh a écrit :
>
>> Hi again,
>>
>> Thank you for your suggestion, I have registered my application at GSoC
>> and I am quite nervous at the moment as the deadline approaches.
>>
>>  I thought of integrating geochat into my application, I think the way
>> geochat works it is possible to get travel schedule by SMS by using it but
>> we will need some more features. (I have proposed the idea on GeoChat
>> Feedback forum
>> http://geochat.uservoice.com/forums/7328-geochat-feedback-forum under the
>> name Route Plan )
>>
>>
> I just voted for your idea.
>
> I looked into the Geochat API. By using it, we can create a complimentary
>> group on geochat whenever users creates a group for group connect feature.To
>> use this feature user will be provided an option to join Geochat and provide
>> his geochat alias.User will be sent a request to join the newly created
>> group on geochat. Since geochat will store the current location of user
>> whenever user sends a message to it and also forward it to the other group
>> members ,thus the solution for knowing the current position of user when he
>> is offline.
>
>
>> But how does user gets the routing plan by sending a message? This is
>> where I think geochat is insufficient. Unless Geochat adds such a feature
>> this will not be possible to achieve using the geochat service.
>
> Exactly. I t seems that Geochat can help for the messaging and geolocation
> parts. Your project could help introducing a routing feature in GeoChat. :)
>
> Maybe it would not be too hard to get the location info, either implicitly
> (assuming last location sent by user) or explicitly, and feed it into the
> router. Sending the route back might require some special formatting if you
> want to make it fit in 140 characters (how to keep only the "main"
> way-points ?).
>
> A special routing feature where GeoChat might help by storing and sharing
> the locations of group members, and where routing would get closer to your
> idea, would be to specify a "destination user", instead of the usual
> "destination place". By default, the route would be to the user last know
> destination. But if he has allowed me to be kept informed of his location,
> and if he notifies the system that he is moving, than the system would send
> me the route to his next location.
>
> I guess this is only another description of your idea.
>
> If you want to experiment with GeoChat, it's easy to create your own group
> (and there are maybe already groups that would be appropriate for such
> testing).
>
> I think that in general, when a library is available, it is better to try
> to reuse it, even if at first it looks like it's not exactly what you have
> in mind, and thus might slow you down a bit at the beginning. But then, you
> get all the extra functionality that might not have seemed very important to
> you at first, but that could be to your users. And then, if you improve it,
> or make your work compatible with it, you can share your work with others,
> and its usefulness gets multiplied.
>
> Just my two cents,
>
> Best wishes for the success of your application.
>
> Jean-Guilhem
>
Hi,

@Jean :Thanks for showing interest in my project. Also thanks for voting for
my idea at http://geochat.uservoice.com/forums/7328-geochat-feedback-forum.

You have stated one of the primary problems for getting route through SMS.

> Sending the route back might require some special formatting if you want to
> make it fit in 140 characters (how to keep only the "main" way-points ?).


Again we can send user the most important waypoints for the route (also may
be a shortname) and use a code for direction, for e.g for "turn left" use
"L" and so on.But will it fit in 140 chars? quite difficult . So I think we
should provide the user options of break journey, i.e user will get n
different message containing route from 1 point to next and so on. here n
will be the no. of messeges user want to receive or  equivalent to no. of
break journey. More the value of N more detailed will be the route.

Also the idea of a destination user can work wonderfully. To get a route
user can send a message as simple as "@dest route". We can check for new
messages for the destination user, find the message requesting route,
retrieves the message sender's location and calculates the route to the
destination location (location of destination user) , convert to a shorter
format and send to the user again simply messaging "@user .....".

I think that in general, when a library is available, it is better to try to
> reuse it, even if at first it looks like it's not exactly what you have in
> mind, and thus might slow you down a bit at the beginning. But then, you get
> all the extra functionality that might not have seemed very important to you
> at first, but that could be to your users. And then, if you improve it, or
> make your work compatible with it, you can share your work with others, and
> its usefulness gets multiplied.


I think this should work.  What an idea!!!

Thanks ,
Amit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20100411/7109a4fe/attachment.html>