<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Tom,<br>
<br>
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!).<br>
<br>
Lee, I don't think there was an intention to create a new database
of charging locations in OVMS (unless I've missed something).<br>
<br>
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.<br>
<br>
Regards,<br>
Chris<br>
<br>
On 23/05/2014 06:44, Tom Saxton wrote:<br>
</div>
<blockquote cite="mid:CFA3C67D.62043%25tom@idleloop.com" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>Does the transfer to OCM happen from the OVMS server or from
the smartphone app?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div> Tom</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div>
<div>On 5/22/14, 3:02 PM, "Paul Churchley" <<a
moz-do-not-send="true" href="mailto:paul@churchley.org">paul@churchley.org</a>>
wrote:</div>
</div>
<div><br>
</div>
<div dir="ltr">I agree with Tom. That makes sense from a data
and functional design perspective too. <br>
<br>
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.<br>
<br>
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.<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 22 May 2014 22:49, Tom Saxton <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:tom@idleloop.com" target="_blank">tom@idleloop.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd like to make sure that whatever happens with OVMS
reporting charging<br>
station information stays open and stand-alone, not tied
exclusively to<br>
OCM.<br>
<br>
When a user chooses to submit data, it should go to OVMS
where it can be<br>
accessed by anyone, whether it's a charge map vendor, some
other<br>
enterprise, or someone doing EV research for some
completely different<br>
purpose.<br>
<br>
It's fine if there's a layer of top of that so that OVMS
users who opt-in<br>
to OCM can enter OCM credentials, disambiguate between
possible sites,<br>
etc., and the data also gets sent to OCM.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tom<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
<br>
_______________________________________________<br>
OvmsDev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>
<a moz-do-not-send="true"
href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev"
target="_blank">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
_______________________________________________
OvmsDev mailing list
<a moz-do-not-send="true"
href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a moz-do-not-send="true"
href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</span>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</body>
</html>