Support for networks charging apps

[iboboc]

This is a feature request that I consider unique and game changing. It is a simple implementation in app and one change in system.

The issue:

• There are hundreds of apps for charging, browsing, etc
• Every network has his own application to monitor and control charging.
• Usual user if looking for a charger, should first check in an app like OCM the nearby chargers then identify the network, search for his website/smartphone app, open/install it and use it.

The proposed implementation is:

1. enable in OCM operator/network database a new field to store the name/link/id of his application for Android, iOS, web
2. implement in app, when touch on a location the operator name to automatically detect os and open operator installed application (if not installed to open the store link).

This way, OCM will become the main EV owner app as a starting/first point to control access to any charger form any network.

Or, if not the purpose of OCM app, it will be nice to implement in the database and include that in the API to allow other apps to be able to do that.

[webprofusion-chrisc]

Thanks, this is a great idea and we can implement this using our metadata system - we have a general method for "tagging" locations with arbitrary information which we currently only use for data attribution for address lookups but it's actually intended so you can tag a POI with any information (cross references to other databases, links, amenities nearby etc).

The main thing holding this back is setting aside time to do it - I work full time on a completely different business :)

[iboboc]

Fully understand, same here and I guess for everyone. Nevertheless, at least if you can briefly document the necessary changes: what and where, maybe someone can pickup and you'll do only the review/test.

Keep up the great work!

[webprofusion-chrisc]

Thinking about this again it's not really the POI metadata feature that we would use, it's the operator details themselves (otherwise we would end up adding links against thousands of POIs instead of just adding once against each operator).

• The operator database model would need a new OperatorLink or OperatorMetadata table to store the links
• The API model would need a property for this list of links in the operator
• We need a new way for users or editors to submit changes or operators as the list is already too long for a single administrator to look after - this is a little complex as it needs:
  • a way for users to add operators and edits
  • a way for country editors or administrators to review changes and approve/reject them
  • when operator info changes the cached data we hold needs to be refreshed for all related POIs

[iboboc]

I suggest for the first step to open operators edit only to country editors for easier management.