Feature request: "Ladeweile" import of own POIs e.g. from local OSMand files

[issteve]

If we go on holidays we are not keen on going the fastest way to one destination with the closest or fastest charging stations on the way. (Our EV doesn't really charge fast anyway. ;-) )

We like to plan our trips more along certain interesting sites (in our case museums, caves, ruins and other archaeological sites) with fitting charging stations close by. So we are not going straight to one far away destination along fast charging stations, but prefer to find nice stops more or less in the preferred direction. "Der Weg ist das Ziel."

Our favorite spots along our direction are already favorites in their own folder on OSMand and available as .gpx from a local folder free to access for all (under Download or /Android/media/ ).
They can easily shared as gpx via the android share function directly to another app, too.

To manage our Ladeweile it would be great to have a possibility to see in EVMap which of our favorite sites are close to our (filtered) possible charging stations.

So there could be some ways to fulfill our purpose handling the Ladeweile:
e.g.

• accepting gpx files via the Android share function and showing them with special markers (and having the option to delete them again after use)
• option of importing of personal POI-gpx-files from the local storage
  (or maybe with more effort:
• different filters for showing OSM-POIS directly from OSM
• importing, creating, exporting, deleting of own POIs)

It would be helpful to add own charging possibilities (e.g. from accommodations) missing in the data of the different data providers, too.

[johan12345]

The first option sounds the easiest to implement, as it doesn't require much additional UI, just something to parse locations from GPX files and a way to display multiple non-charger markers.
The mechanism could be similar to how currently EVMap already accepts single locations through the share mechanism and displays them with a marker like a search result.
https://github.com/ev-map/EVMap/blob/master/app/src/main/java/net/vonforst/evmap/MapsActivity.kt#L119-L130
https://github.com/ev-map/EVMap/blob/master/app/src/main/java/net/vonforst/evmap/fragment/MapFragment.kt#L1195-L1196
Would you like to work on this?

[issteve]

Thank you for your answer and hints! I'm just sorry I never did something like this. My projects are usually simple bash scripts which are far away from an android app.

Anyway, I did take a look at a gpx file and I think I could easily parse them into geo:. But how would I hand over not only geo: but the name and more information, maybe even the icon and more then one geo at a time? Maybe it would be easier to hand over the whole gpx and parse it in EVMap into e.g. favorites... If you could point me to a place where I can find more about the structure/method for adding/storing/handling favorites and where it would be good to have the conversation from the gpx into those favorites, I would like to look more into this...

[johan12345]

But how would I hand over not only geo: but the name and more information, maybe even the icon and more then one geo at a time?

True, I don't think that is possible with only geo: URIs. What I meant was passing the whole GPX file into EVMap using Android's sharing mechanism (https://developer.android.com/training/sharing/receive) instead of a geo: URI, and then doing the parsing within EVMap. The display part would work similarly to how it's currently done with geo: URIs (i.e., separate markers with a different icon than the one that is used for charging stations).

Favorites as they are currently implemented won't really work well for generic POIs, as they are always linked to a charging station in the data source. But do you really need persistence of such POIs within EVMap (which would bring EVMap already much closer to a general-purpose mapping app like OSMand, and I'm not sure if I want to reinvent the wheel here) or would a one-time display (triggered by sharing/opening the GPX file with EVMap) be enough?

[johan12345]

It would be helpful to add own charging possibilities (e.g. from accommodations) missing in the data of the different data providers, too.

By the way, you can also contribute these back to the data sources - I think most of them have a field to indicate that the charger is only accessible to guests/customers.

[issteve]

But do you really need persistence of such POIs within EVMap [...] or would a one-time display (triggered by sharing/opening the GPX file with EVMap) be enough?

Thank you very much for your ideas and figuring out more about this.
When starts/ends "persistence" or "one-time display" in this case? I often have to "close"(?) the app to switch to another one and it wouldn't be helpful if I would have to start getting the POIs every time I left the App again. If this is about a matter of a forced cache cleaning or system restart, I guess it wouldn't be needed to be /that/ persistence.
But if only switching between apps or an automatic closing of the app by the android system would erase the imported POIs, I think it could be annoying.

But in the case of such a "fast" deletion of the POIs, I think it could be helpful anyway by having the possibility to export the charging station favorites to one gpx (or directly share them all together to OSMand). So it would be possible to mark in EVMap the corresponding charging stations along the imported POIs as favorites first and match them later again with the POIs in OSMAnd (where the EVMap favorites could be persistent together with the POIs).

So, how long would the "one-time display" last or when would the imported custom POIs gone?

[johan12345]

So, how long would the "one-time display" last or when would the imported custom POIs gone?

The Intent that started the app, which contains the information on the shared GPX file, should stay available for as long as the app is not restarted using another Intent (e.g., sharing another GPX file, location, or charging station with EVMap). So switching to other apps inbetween is fine. Only if the app gets killed by the system due to low memory, that will probably get rid of the Intent as well.