Cloud exports

[andrea antonello]

Dear all,
in the last couple of years I have seen a growing contribution of
cloud projects for geopaparazzi.
This is a fantastic thing but is bringing a bit of instability to
geopaparazzi itself, since I do not want to have 200 import/export
entries for the different projects that want to sync geopap.

As some of you might know, I recently developed a sync server [1] that
has a standalone app on the android side. It seems to work quite well
and interacts with the database directly (not with the app). It
obviously has ups and downs, but for sure keeps geopaparazzi clean.

So I am tempted to follow this way for any cloud solution.
That means that if we all agree on this each sync solution will have
to supply its android app. That app will handle not only sync logic
but also credentials.

I would then also have just one single import/export entry named
"Cloud Sync" that will look for an intent and pass to that one the
current database path, so that the sync app can be directly called as
integrated from geopap if that is a wish.

What do you think?
Cheers,
Andrea

[1] http://geopaparazzi.github.io/geopaparazzi/gss/geopaparazzi_survey_server.html

[Brent Fraser]

Andrea,

Difficult questions. Ease of use (for the end user) should be the
guiding principle, but balanced with ease of development (enhancement,
maintenance).

I think if just upload/upload Project file records is required, then a
separate app like Geopaparazzi Survey Server Sync is a good way to go,
especially if it can be kicked off from Geopaparazzi. But if we want to
more automatically download files and configure Geopaparazzi like the Cloud
Profiles do, then perhaps the best way to go is integrating the code within
Geopaparazzi (as we're doing with the Cloud Profiles).


One important consideration is to document the protocols used in the two
solutions mentioned above so developers can build their own server-side
solutions if they want.

Is the Geopaparazzi Survey Server Sync code Open Source? Thanks!

Best Regards,
Brent Fraser

[andrea antonello]

> Difficult questions. Ease of use (for the end user) should be the
> guiding principle, but balanced with ease of development (enhancement,
> maintenance).
>
> I think if just upload/upload Project file records is required, then a
> separate app like Geopaparazzi Survey Server Sync is a good way to go,
> especially if it can be kicked off from Geopaparazzi. But if we want to
> more automatically download files and configure Geopaparazzi like the Cloud
> Profiles do, then perhaps the best way to go is integrating the code within
> Geopaparazzi (as we're doing with the Cloud Profiles).

Ok, that might be true. Even if I am not happy with the fact that it
is a bit misleading. Right now profiles is very powerfull, but it
doesn' give you real sync.

> One important consideration is to document the protocols used in the two
> solutions mentioned above so developers can build their own server-side
> solutions if they want.

Actually, what I am proprosing is to be protocol agnostic. I.e. if you
use an external app (that might be opened through an intent) you
define you protocol and your way of doing the sync.
I think this is the great part, since when it comes to sync, everyone
has different needs and wants different protocols. That is what I
found out.
So the only way, in order to not have to choose which sync engines to
include in geopaparazzi core, the only way to do it is to have them
outside.
At least that is my thought. Because other wise we already now would
have the profiles sync, the project data sync and gvsiglonline has
some spatialite sync.
I don't want to be in the position to choose, else I will simply
choose mine :-) So to be fair, I propose to keep them all outside and
work on exposing the right stuff for it.

> Is the Geopaparazzi Survey Server Sync code Open Source? Thanks!

Yes absolutely, the currnet is EPL2. The only thing is that we are
currently testing a technology switch and don't want to release the
code before beign sure with what we will stay.
So once that is sorted out, we will make all available on open repos.

Cheers,
Andrea

[César Martínez]

Hi Andrea,

It sounds reasonable for me to keep sync out of Geopap and just to
expose anything required to make this happen.

Best regards,

César

> --
> You received this message because you are subscribed to the Google Groups "geopaparazzi-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to geopaparazzi-de...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
SCOLAB
http://scolab.es

[Brent Fraser]

-------- Original Message --------
> From: "andrea antonello" <andrea.a...@gmail.com>
> Sent: Thursday, August 2, 2018 2:37 AM
> To:
> Cc: "geopaparazzi-devel" <geopapara...@googlegroups.com>
> Subject: Re: Cloud exports
>
> > Difficult questions. Ease of use (for the end user) should be the
> > guiding principle, but balanced with ease of development (enhancement,
> > maintenance).
> >
> > I think if just upload/upload Project file records is required, then a
> > separate app like Geopaparazzi Survey Server Sync is a good way to go,
> > especially if it can be kicked off from Geopaparazzi. But if we want
to
> > more automatically download files and configure Geopaparazzi like the
Cloud
> > Profiles do, then perhaps the best way to go is integrating the code
within
> > Geopaparazzi (as we're doing with the Cloud Profiles).
>
> Ok, that might be true. Even if I am not happy with the fact that it
> is a bit misleading. Right now profiles is very powerfull, but it
> doesn' give you real sync.
>

Currently that's true; it's one of the many things on our ToDo list for
the client/server configuration.

> > One important consideration is to document the protocols used in the
two
> > solutions mentioned above so developers can build their own
server-side
> > solutions if they want.
>
> Actually, what I am proprosing is to be protocol agnostic. I.e. if you
> use an external app (that might be opened through an intent) you
> define you protocol and your way of doing the sync.
> I think this is the great part, since when it comes to sync, everyone
> has different needs and wants different protocols. That is what I
> found out.
> So the only way, in order to not have to choose which sync engines to
> include in geopaparazzi core, the only way to do it is to have them
> outside.
> At least that is my thought. Because other wise we already now would
> have the profiles sync, the project data sync and gvsiglonline has
> some spatialite sync.
> I don't want to be in the position to choose, else I will simply
> choose mine :-) So to be fair, I propose to keep them all outside and
> work on exposing the right stuff for it.
>

My goal is make Geopaparazzi more user-friendly so even non-GIS users will
find it easy to use and be productive. To that end, I think that it is
important to have the Cloud Profile import/export ability integrated within
Geopaparazzi and not a separate app. On the other hand, for experienced
GIS users accustomed to using multiple apps to complete their workflow, I
think a separate app like GSSS (and others) is fine.

> > Is the Geopaparazzi Survey Server Sync code Open Source? Thanks!
>
> Yes absolutely, the currnet is EPL2. The only thing is that we are
> currently testing a technology switch and don't want to release the
> code before beign sure with what we will stay.
> So once that is sorted out, we will make all available on open repos.

Sounds good. Thanks!

[Peter Heerink]

Hello,

I 'm creating a solution for a greencompany, that works with several different complex forms.

I have created these complex forms using brackets ( https://github.com/adobe/brackets/)

Further I'm using the profile feature  for the setting of:

 - fixed projectfile (gpap)

 - complex forms (JSON)

 - used Map (.map)

Next to that I use the export PDF feature to export the reports to geopaparazzi/export folder

Each of these files are now hold in a seperate folder on the device.

These folders are synced to a Company Google Drive account for administration and update

-

For the sync I 'm using an app called Drive Sync  

https://play.google.com/store/apps/details?id=com.ttxapps.drivesync&hl=en

- New .map and changed forms are so uploaded to the devices by wifi (download from google drive)

- Gpap , backup (upload to google drive)

- Export PDF to the company ( upload to google drive) 

Greetings

Peter

.

 

email to geopaparazzi-devel+unsub...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "geopaparazzi-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to geopaparazzi-devel+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Met vriendelijke groet,

Peter Heerink

http://www.historischekringlosser.nl/

https://sites.google.com/site/cimicresources/