RFC: Basic NOBIL implementation #363
Conversation
robho
force-pushed
the
nobil
branch
3 times, most recently
from
80cdd5e to
d0c19e3
Compare
|
Very nice, thanks a lot! I'll try to find some time in the weekend to try it out and provide some help with code cleanup.
Yeah, if there are properties that don't fit into EVMap's data structure we can think about adding new fields or expanding existing ones where it is useful. For payment methods, we have the
As previously mentioned, I guess all the filters would have to be implemented locally, as the Nobil API doesn't really have server-side filtering abilities, right? That should be possible (just like the min_connectors filter for GE and OCM), but in the longer term the better solution is probably to first download all chargers into the local DB (which is a capability I'm implementing for #290) and perform filtering there.
Chargeprice currently only support GoingElectric and OpenChargeMap unfortunately. And by now they have also created their own separate database of charging stations aggregated from different sources, so from what I heard they are not so interested in fixing issues with their adapters for GE and OCM, let alone adding new ones 🫤.
Likely yes, I can test that as well.
True, that is probably a general bug - for GoingElectric it's not so relevant as we are only allowed to cache the data for 24h anyway. But yeah, it probably also applies to OpenChargeMap. Let's track that in a separate issue. |
app/src/main/java/net/vonforst/evmap/api/nobil/NobilAdapters.kt
Outdated
Show resolved
Hide resolved
| // 24: Open 24h | ||
| if (chargerStationAttributes.st["24"]?.attrTrans == "Yes") OpeningHours(twentyfourSeven = true, null, null) else null, | ||
| // 7: Parking fee | ||
| if (chargerStationAttributes.st["7"]?.attrTrans == "No") Cost(freeparking = true) else null, |
There was a problem hiding this comment.
If the attribute is set to "Yes" (i.e. known to have a parking fee), you could also set it to Cost(freeparking = false). It should only be set to null if the parking fee is not known.
There was a problem hiding this comment.
Other fields from Nobil that might be relevant to the Cost - maybe these could be used to generate a description?
- Time limit
- Accessibility (does
Openmeanfreecharging?) - Payment Method
There was a problem hiding this comment.
Looks like I either add freecharging and freeparking or descriptions. If I set freecharging and freeparking then EVMap creates a text string for me and ignores the descriptions. Right?
There was a problem hiding this comment.
No, you can also set both - then freecharging/freeparking will be shown in the first line and the description as a smaller text below.
There was a problem hiding this comment.
I added some information to the Cost description:
Accepted payment methods: Bank card, Charging card
I looked into "Time limit" and "Accessibility", but they were not reliable and consistent.
| null, | ||
| Instant.now(), | ||
| true | ||
| ) |
There was a problem hiding this comment.
Other than what we already have, I think the Availability attribute ( Public/Visitors/Employees/By Appointment/Residents) would be great to add and also have as a filter (at least as a binary filter - only publicly accessible or all)
There was a problem hiding this comment.
See 70953af. What do you think?
I kept the name "availability" although it could perhaps be confusing when the realtime data code refers to "availability" also.
There was a problem hiding this comment.
Looks good! Regarding the naming... Hm - maybe something like access instead of availability? i.e., a charger could be "available" (not in use) but not publicly "accessible".
|
Regarding filtering..
Is your idea to replace the on-demand-loading with a full data fetch or are you thinking of having some combination of the two? The nobil data is ~130 Mbytes today (up ~6 Mbytes in ~2 months). This is uncompressed data, I haven't checked if the server can compresss data and what the compressed size is. I think I would prefer to use on-demand loading most of the time, but it would be valuable to have the possibility to cache all data when needed (no mobile connection or high mobile roaming prices, ...). Is the problem that you see with local filters that they need to fetch data for chargers that are uninteresting? Ie unnecessary network traffic and data processing? Are those "unnecessary" downloads cached even if they are not used? |
Gzip usually helps quite a lot with JSON data, and the Nobil server does seem to support it. According to the download size is pretty small at just ~5 MB. Of course it might occupy a bit more space in the local database (and from my experience with the implementation for OSM, parsing the JSON and inserting chargers into the DB also takes much more time than the download itself).
In general, EVMap will continue to support both. So we could offer both options for Nobil. On the other hand, with such a small download size, there's not much of a downside to storing it all locally - might also reduce the load on Nobil's servers in the long term.
Yeah. I think the data processing (JSON parsing into Kotlin objects, then filtering) is usually the main bottleneck when loading a large map region with thousands or even ten-thousands of chargers - server-side filtering and even server-side clustering makes it a lot faster for GoingElectric where that is supported. Also, depending on what filters we implement, there might be some filters where we can only determine the available options by iterating through the whole dataset once (e.g., the network filter mentioned in the comments) and then storing that as
not at the moment, because local filtering happens inside the API implementation |
This reverts commit d9be059. It doesn't work to set data dataSource to "nobil.no". I guess that the period in the string confuses EVMap. Maybe related to the db?
nobil has data on biogas and hydrogen "chargers", but we don't want them in EVMap
There's a web page for Swedish chargers, but we need to send email for the other countries.
Remove duplicated url
.. and populate it in nobil data source
I think this is more in line with how other non-existent parameters are handled. Also added some code to merge evseIds when merging Chargepoints.
Nobil has no suitable sites to individual charging stations so url needs to be optional and then we use dataSourceUrl instead in "data source button".
URLEncoder.encode() encodes ' ' as '+' and that's not handled by all email apps. Uri.encode() uses "%20" for ' '.
In the charger details screen, set the share menu item's visibility in the same way as the favorite menu item's state is set.
All valid nobil images are [0-9]+.(jpg|png), all other file name variants should be discarded (such as "coming soon").
In nobil there's a connector type named "Type 2 + Schuko". If this means that both a type 2 connector and a schuko connector is available I think it makes more sense to parse this like a type 2 connector rather than a schuko connector since most people want type 2 connectors. A new EVMap connector type could be created, but it seems to add little value since "Type 2 + Schuko" is only used by a single charging station in nobil, ie the use would be extremely limited.
This adds a NOBIL data source. Data is available in Denmark, Finland, Iceland, Norway and Sweden and the data is collected both from operators via OCPI and contributed by the public.
This is a draft implementation where some functionality is missing. I'm interested in hearing if this is of interest, and if so, what should I fix/work on going forward?
Known problems / missing features: