Last modified: 2012-08-20 23:21:07 UTC
The admin_tree table contains the locations in use in the monuments database. This should be browsable. Fields: * uselang to indicate the requested lang * adm0-4 optional for deeper browsing Without parameters you should get the countries in English.
I think we can ignore language for now. There should be an action=adminlevels api, that lets you specify an admin level and get all children action=adminlevels level=0 value=us should give all adm1 values under adm0=us, and so on.
Cool. Does children = monuments? So the api should be returning monuments, or should it be returning just the admin levels beneath the requested admin level? Thanks!
With the info/understanding I have of this, I put together a first-pass at an api for admin_tree, to fetch child admin levels. Since I don't have commit access to the svn repo yet, you can take a look at the diffs against r741 here: https://gist.github.com/3101814 Note that this includes a few minor fixes/changes to the existing files for style/simplicity and highlights an issue I noticed ApiBase.php when checking for params of type 'integer'.
Created attachment 10858 [details] admin_tree api and data population Since I still do not have commit access, here is a patch of what I've put together at r756. As the API currently exists, there's no sane way for me to be able to return more than an admin zone's immediate children. Also, the topmost node will always be 'monuments'. I looked into modifying both of these points, but both will take a lot of work. Incidentally, this patch also addresses bug 38312. I'm not sure that I put the SQL file or data population file in locations that will make people happy, but it seemed the most sensible in the existing directory structure.
This was resolved in r759.
I see http://toolserver.org/~erfgoed/api/api.php?action=adminlevels&admlevel=1&admval=us-mo How does this browser handle duplicate location names? Wouldn't it be be better to have something like http://toolserver.org/~erfgoed/api/api.php?action=adminlevels&adm0=us&adm1=us-mo ? Also it would be nice if the documentation of the api could be updated (or better, automagicly generated based on the code, need a new bug for that).
At the moment, the API returns the unique id of each location along with the its name and level.(In reply to comment #6) > I see > http://toolserver.org/~erfgoed/api/api.php?action=adminlevels&admlevel=1&admval=us-mo > > How does this browser handle duplicate location names? Wouldn't it be be better > to have something like > http://toolserver.org/~erfgoed/api/api.php?action=adminlevels&adm0=us&adm1=us-mo > ? I do not totally understand what you're looking for here - can you please elaborate? > Also it would be nice if the documentation of the api could be updated (or > better, automagicly generated based on the code, need a new bug for that). Yeah, I will update the documentation once we the functionality settled. At the moment, the API returns the unique id of each location along with the its name and level, and you can query the API based on the unique ID as well (http://toolserver.org/~erfgoed/api/api.php?action=adminlevels&admid=68918). I just updated the checkout on toolserver to pick up the change that includes the unique ID.
Maarten, I've made some significant changes to the api that now allows one to browse the admin zones using your 'breadcrumb' idea. For example: http://toolserver.org/~erfgoed/api/api.php?action=adminlevels&admtree=us|us-ca It assumes that you will always build your tree (breadcrumb) starting with adm0, since that was the use case we mapped out for the app. Each subsequent level is separated with a '|'. I'm reopening this bug since it wasn't totally resolved and I'll await feedback before marking it fixed again.
Some points. * Looks good, much easier, take for example http://toolserver.org/~erfgoed/api/api.php?action=adminlevels&admtree=be|be-vlg|be-vov :-) * I'm wondering if | is going to cause escaping problems (it might be in the wikitext). I think this is a small thing * You probably want to already include an additional field like "value" to include the human readable name. Now we have things like be-vlg, but at some point we'll have "Vlaanderen". We need be-vlg for the deeper level, but Vlaanderen for the interface.
More: * Are you going to sort client or server side? * Encoding problems at http://toolserver.org/~erfgoed/api/api.php?action=adminlevels&admtree=de|de-nw
(In reply to comment #10) > * Are you going to sort client or server side? Server-side as of r866. > * Encoding problems at > http://toolserver.org/~erfgoed/api/api.php?action=adminlevels&admtree=de|de-nw Resolved, wasn't caused by admin tree code.
