[Ovmsdev] Open Charge Map

Fri May 30 05:06:32 HKT 2014

Well guys, I've been spamming chargingnetworks again with e-mails the last
2-3 weeks
To the detriment of christopher's e-mail too
christopher.cook at webprofusion.com
I am slowly guessing that gmail adresses are blocked in many company's,
because answers are very scarce!

So I think the best thing for you guys is if you want a certain network to
be added to openchargemap, you try, and warn christopher,

I try to add stations, via info I find or get on internet.  Without
infringing copyright of other chargingstationmaps.
It's slow, but I do my best

Openchargemap will only grow, and get more accurate the more users, use it!
This is why opendata & interconnection between open databases will be the
future!
The more uses for the database the better!

2014-05-26 3:00 GMT+02:00 Mark Webb-Johnson <mark at webb-johnson.net>:

> Tom,
>
> To be clear: I was only suggesting geofencing at the server
> per-user-per-chargestation level, to determine the user's preference for
> sharing information at this particular station. For the data published, I'd
> rather just send out raw GPS coordinates of the event (with OCM station ID
> as an optional field, if confirmed by the user).
>
> Regards, Mark.
>
> On 24 May, 2014, at 5:06 am, 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 | Fax: +1 360 462 8160
>> lee.howard at mainpine.com | www.mainpine.com
>> _______________________________________________
>> 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
> _______________________________________________
> 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
>
>

-- 
http://home.scarlet.be/jcsaintpo

Get a warning of every update on my site:
http://jcsaintpo.notifylist.com/jc_site.html

My msn space:
http://spaces.msn.com/members/jcstp/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20140529/a79c9e56/attachment.html>