[Ovmsdev] Seeking ideas for 'range' representation

[Nikolay Shishkov]

Mark, 

Display of range can be done in a similar way openchargemap was integrated in one of the nissan leaf apps out there - some of their guys can probably show you. I think it was concentric circles.

Integration of a particular database of charging stations is a mistake - there are at least 20 such out there. On android this could be done much more elegantly by intents - we can have a "visualize range on map" intent (with parameters like - max range, kWh available, weight of car, efficiency) and have different apps implement that intent and create visualization based on the input data. This would be similar in the way the contacts app in your android phone can dial a phone number with the phone app via dialing intent.
I am not sure how would this best be done in the IOS world. 

Note that I am partial - I am the founder of www.uppladdning.nu a database/mapping on charging sites solution for the nordic region and have had some dealings with the openchargemap before.

Nikolay




________________________________
 From: Mark Webb-Johnson <mark at webb-johnson.net>
To: OVMS Developers <ovmsdev at lists.teslaclub.hk> 
Sent: Wednesday, March 6, 2013 2:12 AM
Subject: Re: [Ovmsdev] Seeking ideas for 'range' representation
 
Felix,

Yes, I agree. This is really not something that can ever be 100% - we just want something to represent roughly what is possible and to limit the charge stations that we show.

A nice thing about circles is that it easy to visually estimate 50% (or whatever), so I think the user can do this themselves.

Perhaps the existing outer estimated-to-ideal circle at 50% transparency, then an inner estimated-to-N%estimated circle at 25% transparency? Or is that too complex?

We're also planning to have a feature of show-route-to-charging-station, for a particular selected charging station, and that will be google maps / whatever so will show real distance by road.

Regards, Mark.

On 6 Mar, 2013, at 9:03 AM, felix bonnier wrote:

> Hi Mark,
> 
> The only thing with this is, obviously roads are not straight so a radius will never show a correct estimate.  I think the range estimate would have to be only a percentage of the two values so that the range circle would be more realistic….. Maybe 60% of the values given by the car or something to that effect.  Otherwise you will never make it to the next charge point………. what do you think?
> 
> felix b.
> 
> 
> On Mar 6, 2013, at 8:46 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
>> 
>> Working with the guys at zerocarbonworld / openchargemap on the integration of Open Charge Map to the OVMS Apps, we are trying to find a way to represent range graphically.
>> 
>> The first idea was a circle, centered around the car, with the inner edge of the circle being estimated range and the outer edge ideal range (or vice versa if you are coming down the mountains on a _long_ mountain road). Plugging in the values for my car today, assuming I was somewhere in the centre of the UK, it would look something like this:
>> 
>> <PastedGraphic-4.png>
>> 
>> The idea is to represent the range, and then plot the charge points within (and perhaps also slightly outside) that range.
>> 
>> That is just one idea. What do people think? Any other suggestions?
>> 
>> Regards, Mark.
>> 
>> P.S. Work on the Apps for this has already started, so I would appreciate a quick reply. Nothing too extensive - just ideas.Thanks.
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

_______________________________________________
OvmsDev mailing list
OvmsDev at lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20130305/1ca53472/attachment.htm>