Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

List of supported countries #46

Open
mvl22 opened this issue Feb 25, 2012 · 20 comments
Open

List of supported countries #46

mvl22 opened this issue Feb 25, 2012 · 20 comments

Comments

@mvl22
Copy link
Member

mvl22 commented Feb 25, 2012

An API call will be available shortly giving a list of the countries that the CycleStreets API will route in.

It would be good to list these in the About/Settings area.

@oliverlockwood
Copy link
Member

@mvl22 is this API call available yet?

@mvl22
Copy link
Member Author

mvl22 commented Nov 26, 2016

We do now have a prototype API call, but we need to implement a few things following a policy discussion last night. Will let you know when this is ready.

@oliverlockwood
Copy link
Member

@mvl22 Just skimming through old issues... any update on this?

@oliverlockwood
Copy link
Member

Also, after reading https://support.google.com/googleplay/android-developer/answer/7550024?hl=en I was able to find out that we're currently available (according to the Android Play Store) in UK, Ireland, Netherlands & Czech Republic.

So when that API call is available and we want to include its information, we also need to make sure we keep those settings in the Developer Console in synch.

@oliverlockwood
Copy link
Member

@mvl22 ping

@oliverlockwood
Copy link
Member

I've now switched this to be labelled as "Server issue".

@mvl22
Copy link
Member Author

mvl22 commented Aug 20, 2018

Could you e-mail me about this to remind me to send some more detailed info that I need to check on and I may be able to sort out the thing which has been blocking this.

@mvl22
Copy link
Member Author

mvl22 commented Aug 20, 2018

NB Is there an Android methodology in terms of country IDs that we can adopt by putting them in our JSON output to enable Store availability automatically?

@oliverlockwood
Copy link
Member

Email sent.

I think the most important thing is to return the response with a list of standard 2-letter country codes (perhaps in a tuple alongside their user-friendly names).

I can't find any evidence of being able to programmatically set the availability, but we might be able to programmatically check the Play Store availability in our builds.

The closest I've got in 5 minutes (without having to pay money to anyone) is to hit e.g. https://play.google.com/store/apps/details?id=net.cyclestreets&gl=gb from an incognito browser window; if you then change gb to something else e.g. de, fr, the Install button disappears. So it's doable at the very least in a hacky way 😄

@mvl22
Copy link
Member Author

mvl22 commented Aug 20, 2018

We have an API call which gives a GeoJSON of the exact routeable areas.

The ideal is that when the user clicks on a map location in the journey planner in an area that is outside these GeoJSON zones, there should be a modal dialog stating that “Routing is not available in this location.”

It would be good if the mechanics for this start to be put in place.

@oliverlockwood
Copy link
Member

@mvl22 can you please share details of that "routeable areas" API call - either here or in an email to me?
I can certainly use that info to create the modal dialog you describe (which I would have found useful when in Austria last September!)

In terms of a list of countries, then, I can see a number of options:

  1. Expose another API which gives a list of countries (as suggested by the original description of this issue)
  2. Dynamically generate a list of countries from the "routeable areas" API
  3. Manually work out a list of countries from looking at the API output
  4. You post a list of countries here, and we manually update it every now and again.

@oliverlockwood
Copy link
Member

@mvl22 ping

@mvl22
Copy link
Member Author

mvl22 commented Apr 21, 2020

We're still wary of exposing this internal model via the API.

However, it occurs to me we could just give a static GeoJSON that is shipped with the app, and periodically update this with new releases. I would be prepared to expedite getting this available.

The optimal situation would be:

  1. The app is available worldwide, but the notes in the store state that routing is not available in some areas (and give a broad description of where it is).

  2. The UI should change, so that if the user clicks to set a start/finish point in an area where routing is not available, there is a message stating this.

  3. The UI should show a mask of the areas not covered, i.e. the inverse of the GeoJSON coverage area should be grayed out.

Would those coders on this ticket be interested to implement that?

PS Let's at least manually increase the number of countries in the next main release. Looks like a new release is needed to do that (can't change the existing release).

@oliverlockwood
Copy link
Member

@mvl22 I'm happy with an approach roughly along those lines. One change: when you say "The app is available worldwide" I strongly think we should not release it to app stores which don't have full or significant routing coverage, otherwise we're setting ourselves up for terrible reviews.

Propose you either email me the current GeoJSON, or commit it to the root /assets folder of the repo and ping me, and then we can go from there.

@oliverlockwood
Copy link
Member

I think "coders on this ticket" is just me at present 😂 but others are welcome to weigh in!

@andrewshadura
Copy link

@oliverlockwood, imagine this situation. Someone from, say, Mexico goes to the UK for a student exchange programme for a couple of months in Cambridge. They get a bike and want to cycle around, but no, Cyclestreets is not available for them because they still have a Mexican Google account (it is tied to the billing address and you can only change it so many times a year). Does this make any sense to you? The app should detect the location of the user and tell them the routing is not available if it indeed is not available.

@andrewshadura
Copy link

andrewshadura commented Apr 21, 2020

So the only sensible approach in my view is to release the app worldwide. You can’t get rid of bad reviews no matter how hard you try. People will always find things to complain about.

@mvl22
Copy link
Member Author

mvl22 commented Apr 21, 2020

We got more bad reviews than people asking about making it available. I agree with Oliver on this, after he pointed out that there are of course very large areas with no coverage.

I think now the Beta programme is enabled, we can point people to that who get in contact.

We can review this once new functionality that provides much better in-app feedback to the user is in place, as things will be different then.

@mvl22
Copy link
Member Author

mvl22 commented Feb 9, 2024

We now have a public API call for showing the routing coverage:

https://www.cyclestreets.net/api/v2/routing.coverage/

By default this will have each feature as an area with a property giving the name.

There is also an overlay mode which reverses this, i.e. the routable areas are cut out of a world polygon. This is to enable a overlay that could be clicked on to say routing is not available in that area when a waypoint click is made.

If this can be put in then we should be safe to release the app worldwide.

@mvl22 mvl22 removed the Server issue label Feb 9, 2024
@mvl22
Copy link
Member Author

mvl22 commented Feb 9, 2024

I suggest the implementation is as follows:

  • Download the routing area overlay file (currently 825KB)
  • Cache it for e.g. a week
  • Show it in the journey planner screen (the Photomap should not have it), coloured transparent gray
  • Add a click handler, so that if it is clicked on, a message should come up saying "Routing is not currently available in this area.", and prevent a waypoint being added.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants