| Re: [geogig-dev] Issues in GeoGig for running workflow from QGIS |
Victor,For #2, when you issue the delete, the response you are getting gives you a token that you must use to complete the delete. Once you have the token, you can issues a DELETE request as follows:Again, the HTTP Method should be delete. And you will replace thec215b1fe47b2bb25 with the token value from the response of the initial delete request. It's a 2-part process. GET the token, then DELETE with the token.For #3, you can create a repo by sending a PUT request to <GeoGig server>/repos/<repo name>/init. Based on the URL in #2, a create repo request would be a PUT to:However, this seems to be broken, not working with the latest build.Looks like I've only prevented 1 bug report...Erik MerkleOn Mon, Jul 11, 2016 at 5:32 AM, Victor Olaya <volaya@xxxxxxxxxxxxxxxx> wrote:Hi all
I have finished implementing the complete workflow in the GeoGig QGIS
plugin, and I have identified the following limitations/issues in
GeoGig.
Let me know if there is something that I am missing or doing wrong, or
how I can help with these (opening tickets, etc). I can provide more
details of the issues if needed, including test data, etc
Thanks!
---
1) The remove endpoint doesn't work for layers:
I open a transaction, call remove to delete a tree (using
"recursive=true") and get
{u'Deleted': u'countries', u'success': True}
I close the transaction
However, no changes are made to the repo
2) Deleting a repo doesn't work
Calling 'http://localhost:8182/repos/repo/delete' returns
<response>
<success>true</success>
<token>c215b1fe47b2bb25</token>
</response>
However, the repo is not deleted
3) There is no command to create a tag
4) Is there a way to create a new repo? I see there is an 'init'
endpoint but cannot figure out how to use it
5) There is no way to get the commit id of a tag. You get the tag id,
but there is not way to resolve it to a commit id. Both the manifest
and tags commands do not provide this information.
6) When importing a layer, even if the username and email are supplied
in the URL, GeoGig will complain if there is not a user configured (in
the global config fole or for the repo). It should not be like that,
since they are being supplied. If it has to be configured in advance,
then there should be a way of doing it through the API, which is not
possible now.
7) 'ours' and 'theirs' elements of the JSON object to send for the
MergeFeature endpoint are documented to expect a featureid, but it
should be a commitid. Otherwise, the call fails.
8) cannot resolve a conflict. If i have a conflict for a feature at
"points/myfeature", when using that path for the 'resolveconflict'
command, it complains that the path "points" cannot be found. It
doesnt seem to be able to find the featuretype based on its name
--
Victor Olaya
Software Engineer | Boundless
volaya@xxxxxxxxxxxxxxxx
@boundlessgeo
_______________________________________________
geogig-dev mailing list
geogig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
http://www.locationtech.org/mailman/listinfo/geogig-dev
_______________________________________________
geogig-dev mailing list
geogig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
http://www.locationtech.org/mailman/listinfo/geogig-dev
Gabriel Roldán
Software Developer | Boundless
groldan@xxxxxxxxxxxxxxxx
@boundlessgeo