Geolocation with Wappler and an API

Wappler General How To
#21

@psweb - well on the geo and currency side, you’re all set! Note, like you probably saw, the currency free API is limited to only setting the base_currency so that the visitor sees your amount in their currency. The fully fledged from/to currency API that allows free-range queries from any currency -to- any currency is only included in the paid premium package.

But that is totally not what this challenge is about! You have everything available on the geoplugin.net API to fully flourish in the geo section of the challenge and it looks like you’ve clearly got the flesh in your jaws to rip it to shreds!

Looking forward to how you exploit to the max what our API offers!

Best of luck :smiley:

2 Likes
#22

euro station data added (whopping 36k rich dataset - includes metro so far as I can tell but doesn’t differentiate between train or metro so far as I can tell) and US Amtrak stations (528 stations) added

2 Likes
#23

Great news, thank you.

Now while I have you for a second, would love to ask another questions.

Because your Airport data just happened to give IATA codes, I decided well maybe i could hook up a flight booking API as well to the setup. That is working fairly well so far however there is one strange thing.
All the prices from the Flight Booking API are by default in Indian Rupees, is there a way to set the Base Currency just for that data to Indian Rupees so your currency converter can convert it to the users currency at the same time?

#24

If I understand well, you want the currency convertor included in the output? If so, no can do because that goes against what an “extra” is - a single specialist type of lookup (and often falling under the umbrella of reverse geocoding, not IP geolocation).

Going by the that logic of providing currency for transport lookups, one could say, just give everything in a single output in a massive array. Yeah, could do, but add about 2KB to the output for which 99.9% won’t use!

If you need the currency also, I’m afraid another default IP geolocation lookup will be required with default currency specified to get those data.

1 Like
#25

Ok, that makes sense, I have an idea i am going to test out and will let you know if it works and what sort of impact it has on speed.
Thanks for explaining, much appreciated.

#26

So I have managed to do it by adding a second call to the geoPlugin api and setting the base currency, if i am only returning the one piece of data does that hit your servers just as hard as if I returned all the data or not from your base api?

<dmx-api-datasource id="api6" is="dmx-fetch" url="https://ssl.geoplugin.net/json.gp" dmx-param:base_currency="'INR'" dmx-param:k="'bbb'" noload="noload"></dmx-api-datasource>

This is the api call I am making.

{{(api6.data.geoplugin_currencyConverter * fare.childtotalfare).formatCurrency(api6.data.geoplugin_currencySymbol+' ', ".", ",", "2")}}

This is how I am returning the call.

#27

I’m missing what “hitting as hard as if…”? In what you gave, you’re simply calling the basic IP geolocation lookup but modifying it a bit by changing the default currency - this has zero impact on geoplugin.net compared to whether you didn’t specify base_currency.

However, what I would be very interested in (if you have a SA IP, which is quite a way from Holland where our structure is located), is a microsecond time from “call” to “response” for:

  1. Basic IP call with base currency changed
  2. A call to the new nearest_transport “extra”
  3. 1+2 in separate calls (how long does it take to do both lookups)

Because following on from what I said, it is possible to add add an “include” parameter in an “extras” call, to say include currency. This clearly would be less overhead for you and us rather than you making two calls. I’m open to implement this, but would like to see first an (honest) microsecond timing of each of 3 above to see how much the end user benefits in latency!

-edit to clarify why we “can’t” include everything in a single lookup -
most of the “extras” are reverse geocoding, taking lat/lon values and as such use a geospatial database. While querying a geospatial database index is lightening fast, it is however extremely RAM intensive (for hitting the index almost immediately) or CPU intensive if it has to “wander” ie 100miles…

1 Like
#28

Great, I am just not wanting to give people info on how to do things in Wappler that might negatively impact your servers so thats why i ask.

Here is the terribly ugly page of data i have so far which i need to format still, I will not use half of the data that is currently on it but i have bound all possible data right now while i do my testing.

https://www.africacollectionbs4.com/test.php

I have had to use noload on many api calls so it does a location lookup first through wapplers built in component, then it calls your geoplugin base base and extra apis, then it calls the flight booking system api, and then geoPlugin one more time to convert the flight prices to the users currency.

EDIT - The flight system data I am using is https://developer.goibibo.com:8080/docs if that also helps you see what i am getting.

1 Like
#29

That is one hell of a beautiful set of data!!!
Well bloody done!
–edit
except if I deny location :stuck_out_tongue:

1 Like
#30

Hahahaha, it has been a blooming nightmare to try get it all in there and work seamlessly together.

Yes please don’t deny location, if you stopped your service ever with this in place i would be in for some great fun. LOL

#31

I meant browser-requesting location deny, not geoplugin - I click “Deny” when it asks to use my location and everything is zero

#32

I would be very interested to see what you could do with all this data, trains, busses, flights, real time hotel data, flight data etc. All powering https://www.goibibo.com/

#33

Ahh, yes, if the user does that then everything is broken, I should try and do a failover solution there, thanks for thinking of that, i will work something out.

#34

Bug?

/json.gp & /extras/postalcode.gp

uses my IP
but

/extras/nearby.gp

seems to be a bug -
if I’m on my UK VPN, it shows nearby places to my actual location (S. France), but if I turn the VPN off, I get SA locations…

I thought at first that this was linked to my VPN, but SA locations if I turn off???

details

DATA OUTPUT /extras/nearby.gp

Place: Kloof
Country Code: ZA
Region: KwaZulu-Natal
Latatude: -29.7852900
Longitude: 30.8232500
Distance Miles: 3.13
Distance Kilometers: 5.04
Direction Angle: 179.61
Direction Heading: S

whether VPN is on or off,

/json.gp & /extras/postalcode.gp

gives the expected results…

#35

fall back to the much poorer IP geolocation using… geoplugin :wink:

#36

ahh, yes, i have hard coded some stuff in there while i was testing, but i will be making some major alterations pretty soon, as soon as i figure out how the heck https://www.goibibo.com/ managed to make such a nice system out of the same API data they are providing me, lol, I am quite a ways off still sadly.

Lol, fall back to the IP Geolocation certainly, so if they block the Wappler one then it should failover to yours which does not need them to allow, best of both worlds.

#37

Their API Schema actually confuses me quite badly, as they have arrays inside arrays and inside those more arrays, and it seems like there is no fixed structure, its like depending on what you search for it could go 10 arrays deep, and on another search it stops at 3 arrays deep.
So not really sure how I am going to handle that, or if I am just crazy and reading things wrong. Which is certainly very possible.

#38

one thing that may drive you crazy also besides arrays without end is that geoplugin extras requires the values “lat” and “long” rather than the standard “lat” and “lon” - if “long” isn’t present (by specifying “lon” instead), it will default to IP.

#39

hmm, well that certainly is some great info, one of the problems i was having earlier now makes more sense. Thanks for telling me that.

1 Like
#40

note to self - add “lon” alias for “long” to solve this!!!

–lon alias added 20181112

2 Likes