Add official geographical relations about country-codes HOT 12 CLOSED

@ewheeler any thoughts here?

from country-codes.

Hello, perhaps the task is not so simple... There are "call for community" channel to this kind of situation?
Even for me, without a good geoprocessing env on my laptop, isn't possible accomplish... I can help (!), if some one manage PostGIS (or similar) and a good "mundi map", see scripts below.

I dont't know the best and updated mundi map, perhaps FAO or geocommons...

The standard OGC functions are ST_Touches() and ST_Intersects(). The script that generate this new columns for country-codes dataset (neighbor_list and utmzones_list) is:

-- Get neighbor_list column for country-codes.csv
SELECT 
    m.ISO3166_alpha2 as ref_country, array_agg(scan.ISO3166_alpha2) as neighbor_list 
FROM mundi AS m INNER JOIN mundi AS scan 
     ON (m.geom && scan.geom) and ST_Touches(m.geom, scan.geom)
WHERE m.id>scan.id;

-- Get utmzones_list column for country-codes.csv
SELECT 
    m.ISO3166_alpha2 as ref_country, array_agg(scan.zone) as utmzones_list 
FROM mundi AS m, utm_cells AS scan 
WHERE (m.geom && scan.geom) and ST_intersects(m.geom,scan.geom)

NOTE: the convention here, as ST_Touches, is that "one-point intersection" is valid (illustration).

from country-codes.

@ppKrauss @rgrp I'm not sure this fits well here, partly because this doesn't look simple to generate and also may be difficult to maintain.

however, i think it might be useful to include some IDs that would help folks with spacial tools. OSM has IDs, but these change when the shape is edited, so again this would be a big maintenance burden for what is otherwise a relatively static dataset.

open to ideas for this, but also feel that ISO country codes are going to be a pretty decent key for mapping this dataset into spacial tools.

from country-codes.

@ewheeler I agree that it is not so simple, as run a Perl or Awk with some wget data... But where the Project standards or Project guide say that data preparation is a "computationally limited" algorithm?

It is easy when I have tools (I've worked with GIS but not working in nowadays), I think that in the next month I will prepare this SQL scripts on my laptop...

... But, perhaps this issue is a opportunity to check two things,

1. There are some one in the community (typical people of OSM) that can replace me to maintain? The "other people existence" is a good indicator that the preparation is simple for people that installed PostGIS (or any other OGC-compliant tool).
2. There are some README in this project explaining what is a "good and simple preparation process"? The preparation process of each dataset is, perhaps, the most important part, for future automation, for replicate in other community, or for a kind of "legal proof" (or usual scientific reproducibility).

from country-codes.

@ppKrauss yeah the generation/maintenance is not my biggest concern.

this dataset is called country-codes and attempts to aggregate standard identification codes for the countries of earth.
i think including identification codes that will enable or enhance GIS/spatial integration of these codes makes a lot of sense, but a list of neighboring countries is not a standard code for referring to a country and falls outside of the scope of this dataset.

from country-codes.

hum... Returning to the begin, and using column names,

• neighbor_list: list of "neighbor countries" of each country. It can be a ISO3166-1-numeric list or a ISO3166-1-Alpha-2 or a ISO3166-1-Alpha-3...
• utmzones_list: list of "UTM grid cells" of each country. This column is an enhance and is compliant with the contry-codes dataset goals: "will enable or enhance GIS/spatial integration of these codes", as you say.
• a list value can be a sequence of values separated by space, is usual in CSV files.

You called into question the neighbor_list: I think ISO3166-1-Alpha-2 is the most popular, but for precision perhaps better a ISO3166-1-numeric list (ok to change?).

About neighbor_list (curatorial) motivation: there are a growing and big use in (simple and complex) online geoprocessing applications, that need this kind of (reliable) topological information... And many other scientific, even educational applications that need "fast answer-database". As "knowledge" is so important or more tham FIFA or MARC.

PS: sorry my English if it sounds strange, isn't my language :-)

from country-codes.

@ppKrauss sorry, my point is that neighbor_list is not a standard or a code for identifying countries. this dataset is for collecting various identification codes used for countries (like ISO3166, FIFA, MARC, GAUL, etc). regardless of the contents of neighbor_list, the list itself is not an identification code so is outside of the scope of this dataset

from country-codes.

Well, lets split the discussion into resolved and unresolved topics:

• Resolved: the utmzones_list was approved, need only a collaborator plugged into a "geoprocessing machine". The script is here, and we need only to wait (me or a new collaborator).
• Unresolved: neighbor_list is under discussion... My suggestion is to wait another curator to check personal points of view, because I not understand what is "outside of the scope" in a recurrence relation... See also #5 or #15 lists, they are in the scope? Is a curatorial question.

from country-codes.

Hi @ppKrauss
neither of these are standard identification codes used to identify countries, so I don't think either fit within the purpose of this dataset. I'd recommend creating a separate dataset for geospatial country information

from country-codes.

@ewheeler I'd +1 your thoughts here.

from country-codes.

Thanks @ewheeler and @rgrp (!). I think that, even utmzones_list will fit better into this new "country-geoinfo" dataset... And we can think in "geotime" for merge with #5 issue. It is ok?

from country-codes.

@ppKrauss great. yes i think timezone info would also fit well with these data in the new dataset

from country-codes.