[Ovmsdev] Open Charge Map

[Christopher Cook]

Hi Tom,

That sounds like broadly the correct process to me. The key thing for 
making the info useful to other users is identifying the specific 
charging location, OCM is capable of holding references to other map 
vendors charging locations and associating them as metadata tags 
attached to the charging location in OCM. So OCM can (and is supposed to 
be) a central list of charging locations, which can have pointers to the 
same location in other vendors systems. Vendors could use the OCM API to 
work out which of their charging locations was checked into using this 
metadata. Obviously if the checkin goes to PlugShare directly then we 
can't get that info, as they won't give OCM an API key (currently.. did 
try that!).

Lee, I don't think there was an intention to create a new database of 
charging locations in OVMS (unless I've missed something).

Note that OVMS doesn't strictly need to go through authentication to 
post checkins/comments to OCM as a single OVMS user. We can provide an 
API key to OVMS that works indefinitely and posts/adds/edits as that user.

Regards,
Chris

On 23/05/2014 06:44, Tom Saxton wrote:
> Does the transfer to OCM happen from the OVMS server or from the 
> smartphone app?
>
> It seems to me like it should happen on the smartphone. I'm charging. 
> I want to send in the data. The first step would be to authorize 
> sharing the data, which sends it to the OVMS sever, now publicly 
> accessible to anyone. Next, OCM code on the smartphone runs to see if 
> it has a single matching site, multiple nearby sites, or no nearby 
> site. Depending on how that turns out, I need to either confirm the 
> correct site, choose from a list of candidates, or create a new site 
> if none seems like a match. Once the (possibly new) site is confirmed, 
> then the data goes to OCM associated with that site. That conversation 
> can't easily happen as a post process on the server.
>
> This could get interesting in multiple dimensions. Maybe another map 
> vendor wants to add support to OVMS, so the user can choose OCM or 
> PlugShare, or whatever. Or maybe choose multiple. Or it could happen 
> the other way around: another map vendor integrates the OVMS API into 
> their app.
>
> It seems complicated to do this on the server side, requiring server 
> integration with each vendor. That's messy and presents new surfaces 
> for security exploits. If it is done on the OVMS server, it seems 
> perfectly reasonable to me to have an API that says "tell me about all 
> of the charging station reports since <date of last query>." That 
> seems easier to secure and more flexible, but does still have the 
> problem of dealing with mapping reports to site IDs potentially from 
> multiple different map vendors.
>
> As an aside, PlugShare is already experimenting with adding the 
> ability to add voltage/amperage info to their database via a special 
> version of their web site that appears when the user agent is the 
> Model S browser.
>
>    Tom
>
> On 5/22/14, 3:02 PM, "Paul Churchley" <paul at churchley.org 
> <mailto:paul at churchley.org>> wrote:
>
> I agree with Tom. That makes sense from a data and functional design 
> perspective too.
>
> It is best if OVMS remain uncoupled as much as possible and pushes out 
> updates to OCM for opted-in users through an external system update 
> layer. That layer could be independent of the main OVMS system and 
> could have stubs for each data interface that OVMS wishes to interact 
> with. That would make the design, development and maintenance of this 
> functionality modular, isolated and easier to develop.
>
> tbh, I would feel uncomfortable with OCM pulling changes in from OVMS. 
> The update originate from within OVMS and so OVMS should initiate the 
> action IMO. So, I would prefer to OVMS charging location capture to be 
> generic and not tied to OCM or to OCM functionality. Of course, OCM 
> and its requirements will impact on the OVMS design but OVMS should 
> remain, wherever possible, external system/database agnostic.
>
>
> On 22 May 2014 22:49, Tom Saxton <tom at idleloop.com 
> <mailto:tom at idleloop.com>> wrote:
>
>     I'd like to make sure that whatever happens with OVMS reporting
>     charging
>     station information stays open and stand-alone, not tied
>     exclusively to
>     OCM.
>
>     When a user chooses to submit data, it should go to OVMS where it
>     can be
>     accessed by anyone, whether it's a charge map vendor, some other
>     enterprise, or someone doing EV research for some completely different
>     purpose.
>
>     It's fine if there's a layer of top of that so that OVMS users who
>     opt-in
>     to OCM can enter OCM credentials, disambiguate between possible sites,
>     etc., and the data also gets sent to OCM.
>
>        Tom
>
>
>     _______________________________________________
>     OvmsDev mailing list
>     OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>     http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
> _______________________________________________ OvmsDev mailing list 
> OvmsDev at lists.teslaclub.hk <mailto: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/20140523/ec89604f/attachment.htm>