You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 28, 2020. It is now read-only.
The boundaries relevant to a particular election are currently associated with a particularly MapIt generation and one or more area types. In MapIt Global, however, an area type of O05, say, refers to boundaries with admin_level 5 throughout the entire world. That means that this code, will typically try to download the metadata about far too many areas (and for most types in MapIt Global, the request will time out and never complete).
Ideally we would like people to be able to use MapIt Global to make it quicker to set up a YNR instance (assuming it contains the boundaries they need) so this needs to be changed. I think ideally you should be able to specify an optional "containing area ID" with an area type, so that the code that fetches areas will only fetch areas of that type which are covered by the containing area.
General queries (without any geometric part) should be fine and not time out, though as you say will download too much information (but if that's ignored, should be workable). Geometric queries will be too slow in general, I think (depending on size of area); storing the country in the country field in global MapIt (see mysociety/mapit#55) might be a better solution.
Can you explain how to save the covers query to the expected cached filename? I would like to use MapIt Global but can't figure out how to add these area types.
YNR no longer loads areas from disk. A script was added back in December for importing areas and posts directly from MapIt; you need to supply it with the MapIt URL, the OSM boundary level and a slug/ID format string. The script uses 'covers' rather than 'coverlaps' but that shouldn't matter. An example usage would be: ./manage.py candidates_create_areas_and_posts_from_mapit "http://global.mapit.mysociety.org/area/792633" "O04" "{area_id}". If the IPU info on Mongolia is still current, you might also wanna specify a party set (see ./manage.py candidates_create_areas_and_posts_from_mapit -h). The labels aren't all in Mongolian Cyrillic, though you could modify the script to fetch each district individually; the district files contain a list of names according to language. I hope this helps somewhat.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The boundaries relevant to a particular election are currently associated with a particularly MapIt generation and one or more area types. In MapIt Global, however, an area type of O05, say, refers to boundaries with admin_level 5 throughout the entire world. That means that this code, will typically try to download the metadata about far too many areas (and for most types in MapIt Global, the request will time out and never complete).
Ideally we would like people to be able to use MapIt Global to make it quicker to set up a YNR instance (assuming it contains the boundaries they need) so this needs to be changed. I think ideally you should be able to specify an optional "containing area ID" with an area type, so that the code that fetches areas will only fetch areas of that type which are covered by the containing area.
As a workaround, for the moment, you can construct the right "covers" query (e.g. http://global.mapit.mysociety.org/area/661998/covers?type=O04) and save those results to the expected cached filename.
The text was updated successfully, but these errors were encountered: