Rework Country / City values

[DylanVerstraete]

Right now we are using country_id and city_id both being an integer value that is mapped to what is stored inside our graphql database.

We store these values on following objects:

• Entities
• Farms
• Nodes

When a Node boots, it get's it location from https://geoip.grid.tf/ , this returns ISO 3166-1 2-letter or 3-letter country code and the city name among other values. It would be much easier if we could just pass these values on Node creation instead of doing a lookup on grahpql to find the right city/country id by name values (string search). It also implicates that Zos needs to use another external service that possibly can have downtime and delay node registrations.

We suggest we store country/city values by string as returned from https://geoip.grid.tf/ and then we can do a lookup on graphql by these string values to get more information about a country/city objects as a whole.

Secondly, We suggest to remove the country/city values from a farm because a farm can have nodes in multiple locations.

This also implicates that a user/org (Entity) object needs to pass sane values for country/city on Entity creation.

If we have country codes that are strings and are ISO 3166-1 we can do a query on graphql that is as easy as:

{
   countries(where:{ code_contains:"EG"}) { name, countryId, code, subregion, region }
}

[robvanmieghem]

It would be much easier if we could just pass these values on Node creation instead of doing a lookup on grahpql to find the right city/country id by name values (string search)

You suggest to pass these string values to the substrate extrensic which then does a lookup on graphql? This would cass a circular dependency or do you want to store them in substrate as ISO 3166 values instead of as integers?

[despiegk]

'''because a farm can have nodes in multiple locations''' should we allow this?

[robvanmieghem]

The combination of an external datafeed creating countries and cities in the graphql postgress and later reusing those in the chain data always felt awkward since archtitecturally it's the same db that indexes the the chain data, which is already a circular dependency. Looking at it functionally as a seperate datasource on which the chain relies and is aggregated in the indexed graphql/postgress, then I see no problem

[despiegk]

location from https://geoip.grid.tf/ is not usable

e.g. my location says

{"address":"197.163.85.251","country_code":"EG","country_name":"Egypt","subdivision":"Cairo Governorate","continent":"Africa","city_name":"Cairo","latitude":30.0778,"longitude":31.2852,"source":"maxmind geolite2"}

I am in Gouna 500km away from there, you will have this a lot of times

[robvanmieghem]

what is the exact problem we try to solve with this issue?

[muhamadazmy]

It would be much easier if we could just pass these values on Node creation instead of doing a lookup on grahpql to find the right city/country id by name values (string search)

You suggest to pass these string values to the substrate extrensic which then does a lookup on graphql? This would cass a circular dependency or do you want to store them in substrate as ISO 3166 values instead of as integers?

No, we just provide the country code in the extrinsic. then later whoever wants to get the full country information can use this code to query graphql for full country name and such.

[robvanmieghem]

Ok, so removing the extra graphql call from zos and as a side benefit making the country/city info better updateable.

[muhamadazmy]

what is the exact problem we try to solve with this issue?

The problem is the following:

ZOS use the geo ip service (which is not pinpoint accurate but has correct country information to store this location information on the node object. currently the country/city type on the structure is int which are not standard hence we will need to do an extra lookup from the standard country code (like EG, and BE) to a non standard database to get an int ID (graph ql in this case)

then store the looked up id in the node object. then later on people have to re use this non-standard code int to look up the ocuntry information again from the same database (graphql)

I suggest that we streo the standard country code (EG BE on the node object directly) then people if needed can still use graph ql OR any other country database to look up country name

[muhamadazmy]

Ok, so removing the extra graphql call from zos and as a side benefit making the country/city info better updateable.

exactly

[DylanVerstraete]

location from https://geoip.grid.tf/ is not usable

e.g. my location says

{"address":"197.163.85.251","country_code":"EG","country_name":"Egypt","subdivision":"Cairo Governorate","continent":"Africa","city_name":"Cairo","latitude":30.0778,"longitude":31.2852,"source":"maxmind geolite2"}

I am in Gouna 500km away from there, you will have this a lot of times

Well, location based on IP addresses is not that very accurate. It will give at most an approximate location. This is currently what we are using in Zero OS to pin a node's location.

[DylanVerstraete]

'''because a farm can have nodes in multiple locations''' should we allow this?

I'm not sure, nothing prevents a farmer from booting nodes in different countries right now. Do we want to block this?