[Ovmsdev] Open Charge Map

Sat May 24 06:19:06 HKT 2014

That's a fair point, although I don't think it's especially proprietary
since users can report the same information manually. The stations are all
public.

I'd suggest contacting Kent Rathwell:

Kent Rathwell
President and Founder
Sun Country Highway
kent at suncountryhighway.ca
306-612-4600
800-467-6920

If Kent says it's OK, but can't give you a nice data feed, my script may be
useful.

   Tom

On 5/23/14, 2:46 PM, "Paul Churchley" <paul at churchley.org> wrote:

I think that OCM needs to be mindful of copyright when taking data from
other sources. In fact, I know that Christopher Cook of OCM is mindful of
that. So unless the data at the Sun Country Highway Network is open source
OCM will be cautious of "grabbing" data from anywhere.

This whole area of potential of breach of copyright and data licensing is
something we all need to me mindful of. :-)

On 23 May 2014 22:06, Tom Saxton <tom at idleloop.com> wrote:
> I expect that grouping by geofencing will be helpful, but there will be
> problems, so I think it's important to retain the original longitude/latitude
> coordinates.
> 
> Consider Bellevue Square (700 Bellevue Way NE, Bellevue, WA 98004). There are
> five separate charging sites all within a 300 meter radius circle and all in
> covered parking garages so GPS coordinates will be spotty at best (probably a
> reading from before the vehicle entered the garage). Two of the sites are 5
> feet apart and yet so different they should be treated separately (four
> 208V/30A public ChargePoint stations and a Tesla-only area with one each Model
> S and Roadster 208V/70A HPWC). None of the maps I checked (OCM, PlugShare,
> ChargePoint, US DOE) has it right even if we allow lumping the Tesla stations
> and ChargePoint stations together.
> 
> For example, in OCM the pin for OCM-4350 is in the wrong place by about 100m
> (and is marked as private restricted access). OCM-4310 is in the right place
> for a nearby site, correctly marked as public, but only reports 2 stations
> when there are four. OCM-4311 looks like a duplicate of OCM-4310 but is in the
> wrong place by about 50 m and says it's private restricted access. I could be
> charging at OCM-4350 and even if I had perfect GPS coordinates by some
> miracle, I'd be closer to the arguably bogus OCM-4311 location. Any attempt to
> map from the OCM site record to another vendor's site database will definitely
> fail.
> 
> So I vote for not geofencing; let the charge map folks do that (perhaps with
> help from the OVMS app user). It would be great to have a way to map each
> report to a charge site ID as long as that's flexible enough to allow IDs from
> multiple map vendors. If I'm using OCM, I'd want to map to an OCM site ID. If
> I'm using another map, I want to be able to associate my report with their ID.
> 
> I'm really looking forward to having a charging station map that will let me
> find, and report status on, high-amp L2 stations.
> 
> BTW, it looks like OCM needs to grab the stations from the Sun Country Highway
> network. I have a Perl script that will do it which I'm happy to share.
> 
>    Tom
> 
> On 5/23/14, 1:23 AM, "Mark Webb-Johnson" <mark at webb-johnson.net> wrote:
> 
> 
> I think there is a difference between the charging database (locations) and
> events (charge start/stop by a particular user at a particular time).
> 
> We chose OCM (or did OCM choose us ;-) precisely because we didn¹t need
> another charging database. Both the Android and iPhone Apps have some
> integration to OCM already.
> 
> I suggest the data records for charge events that we publish should be keyed
> on geofencing of the latitude+longitude of the charging event. The OCM station
> ID can be optionally provided by the user, and other consumers could
> cross-reference that to provide correlation to their own databases (if they
> think it necessary and can abide to the OCM license terms).
> 
> Regards, Mark
> 
> On 23 May, 2014, at 4:15 pm, Paul Churchley <paul at churchley.org> wrote:
> 
>> I can see your point Lee.
>> 
>> I see OCM slightly different in that I see it as just one of many potential
>> charging databases out there that OVMS may want to interact with. By using
>> OCM as the charging database of OVMS you remove all aspect of control over
>> the data. The data collected by the OVMS users belongs to them, and by
>> inference to OVMS. Just giving it to OCM as our datastore means that OVMS
>> only has "acces"s to that data via the OCM API... we wouldn't have control
>> over the data itself. We would have lost all element of direct control
>> including where it goes to after OCM. That would then be down to OCM.
>> 
>> If those issues could be overcome, of if people consider these points
>> unimportant, then we could use the OCM database as "our" database I suppose.
>> 
>> Perhaps OCM and OVMS would like to merge projects? Then this issue goes away
>> :-) Just a thought :-)
>> 
>> Smartphone apps are great but I believe that the best place to do location
>> relatively complex and comms-dependent tasks; such as matching, sending
>> updates to OCM etc, is on the OVMS server. What if there is a new database
>> that OVMS wants to update also? The phone app would need updating and every
>> user would need to update their app. In fact, some of that code might be
>> pretty big or complex and that would then reside on relatively low-powered
>> phone devices instead of the server. I wouldn't see this as a batch task. It
>> could still be real-time and triggered by the phone app.
>> 
>> 
>> On 22 May 2014 23:44, Lee Howard <lee.howard at mainpine.com> wrote:
>>> On 05/22/2014 02:49 PM, Tom Saxton 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.
>>> 
>>> Is OCM not open-enough already that it could simply be viewed as the
>>> charging-location database for OVMS?  Why should OVMS duplicate the effort
>>> of developing a charging-location database?
>>> 
>>> 
>>> Lee.
>>> 
>>> -- 
>>> *Lee Howard*
>>> *Mainpine, Inc. Chief Technology Officer*
>>> Tel: +1 866 363 6680 <tel:%2B1%20866%20363%206680>  | Fax: +1 360 462 8160
>>> <tel:%2B1%20360%20462%208160>
>>> lee.howard at mainpine.com | www.mainpine.com <http://www.mainpine.com/>
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>> <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.hkhttp://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/20140523/47e69bda/attachment.htm>