[Ovmsdev] Open Charge Map

[Tom Saxton]

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> 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> 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
> 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/20140522/3c36f60c/attachment.htm>