Hi,
there was some discussions during the spring of the plugin prepair.
Problem was that it needs to have a compiled "kernel", c++, user UI is
in python.
I've tested it now both in linux (openSuse 12.3 and QGIS 2.2 up2date)
and windows (w7pro/64 and QGIS 2.3 nightly latest) environments.
In li
Il 06/06/2014 00:49, Kari Salovaara ha scritto:
> Conclusions
>
> Plugin is useful and thus very acceptable, but
> - it can be installed only by person who knows what to do, those people who do
> digitizing are not always programmers (very seldom)
> - to tell where the actual workhorse is situate
Thank you for your feedback Kari.
I understand that compiling is not for everyone, that's why we offer both
Windows and Mac binaries (we added Mac yesterday). No compiling required.
It is written on the website how to proceed for Windows: unzip to C:\
directly.
A windows Installer would be nice,
Il 06/06/2014 13:17, Hugo Ledoux ha scritto:
> A windows Installer would be nice, but, Paulo, do you mean that QGIS would add
> prepair? That would be tricky, since we use CGAL too. But that would be great.
>
> The plugin should remember the path of the EXE, it does on all computers we've
> teste
I'm not sure just adding it to QGIS like that is the best idea really, it's
a bit bolt on. It would be better to port the prepair C++ logic into QGIS
itself to use QGIS geometry rather then GDAL. We could then just expose the
API and wrap it in Python to expose in Processing.
- Nathan
On Fri, Ju
o mailing lists, twitter, linkedin, and if
> possible on a qgis-news mailing list where we have gathered a lot of user
> beforehand (with their approval of course).
>
> Vincent
>
>
>
>
> --------------
>
> Message: 6
> Date: Fri, 06 Jun 2014
Il 06/06/2014 14:45, Hugo Ledoux ha scritto:
> My colleagues and I are willing to help if there is interest from the
> community in having prepair included in QGIS.
>
> However, I believe, like Nathan, that including the current version is
> sub-optimal: we’re just calling the binary and pass the
On Fri, Jun 6, 2014 at 3:11 PM, wrote:
> I also agree with Nathan: would you like to cooperate with QGIS core team, and
> incorporate your logic, possibly your code, in QGIS itself?
> All the best.
Yes we’re willing to do that. It should be stressed out here that we
use CGAL (www.cgal.org, which
Hi Hugo,
About a month ago, I created a formula for prepair in the OSGeo4Mac
Homebrew tap [0,1].
I would appreciate it if you would review it, and possibly do any pull
requests for changes you feel are appropriate. Specifically, what options
you used to create the new Mac binary for your plugin,
Il 06/06/2014 15:29, Hugo Ledoux ha scritto:
> Yes we’re willing to do that. It should be stressed out here that we
> use CGAL (www.cgal.org, which is GPL) and its depends (GMP, MPFR,
> Boost).
good news. anyone see the dependencies as a problem?
all the best.
--
Paolo Cavallini - www.faunalia.e
Managinng the CGAL dependency would be useful for (SF)CGAL too. Today it's
used only by PostGIS, internally, but maybe its use will extend in the
future (hopefully for 3D in QGIS too!).
giovanni
2014-06-06 17:51 GMT+02:00 Paolo Cavallini :
> Il 06/06/2014 15:29, Hugo Ledoux ha scritto:
>
> > Ye
SFCGAL is a real hard to compile piece of software. Use it on qgis mean to
transformer the qgis in a real hard to compile software .
:)
Il 06/giu/2014 17:55 "G. Allegri" ha scritto:
> Managinng the CGAL dependency would be useful for (SF)CGAL too. Today it's
> used only by PostGIS, internally,
Il 06/06/2014 18:24, Andrea Peri ha scritto:
> SFCGAL is a real hard to compile piece of software. Use it on qgis mean to
> transformer the qgis in a real hard to compile software .
cgal is packaged in all mayor OSs, AFAIK, so no need to compile it.
all the best.
--
Paolo Cavallini - www.faunali
AFAIK it is noto available in debian stabile. Don't ?
Also surely it is not available in RH enterprise.
I guess surely it is available in ubuntu and fedora.
Il 06/giu/2014 18:26 "Paolo Cavallini" ha scritto:
> Il 06/06/2014 18:24, Andrea Peri ha scritto:
> > SFCGAL is a real hard to compile pie
Il 06/06/2014 18:32, Andrea Peri ha scritto:
> AFAIK it is noto available in debian stabile. Don't ?
I do not think our target for QGIS >= 2.4 is Debian stable.
Someone correct me if I'm wrong.
All the best.
--
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/traini
Do you guess the sfcgal is available on windows ?
Il 06/giu/2014 18:38 "Paolo Cavallini" ha scritto:
> Il 06/06/2014 18:32, Andrea Peri ha scritto:
> > AFAIK it is noto available in debian stabile. Don't ?
>
> I do not think our target for QGIS >= 2.4 is Debian stable.
> Someone correct me if I'
Il 06/06/2014 18:41, Andrea Peri ha scritto:
>
> Do you guess the sfcgal is available on windows ?
prepair needs cgal, not sfcgal
all the best
--
Paolo Cavallini - www.faunalia.eu
Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
___
Qgis-deve
I speak of giohappy proposal of sfcgal.
Il 06/giu/2014 18:42 "Paolo Cavallini" ha scritto:
> Il 06/06/2014 18:41, Andrea Peri ha scritto:
> >
> > Do you guess the sfcgal is available on windows ?
>
> prepair needs cgal, not sfcgal
> all the best
> --
> Paolo Cavallini - www.faunalia.eu
> Corsi Q
CGAL is a prerequisite for SFCGAL. I'm not saying we should worry for
having SFCGAL, but analyzing the dependency for prepair is useful for
(eventually) having SFCGAL or whatever else based on CGAL.
giovanni
2014-06-06 18:45 GMT+02:00 Andrea Peri :
> I speak of giohappy proposal of sfcgal.
> I
Hi,
On Fri, Jun 6, 2014 at 10:26 AM, Paolo Cavallini
wrote:
> Il 06/06/2014 18:24, Andrea Peri ha scritto:
> > SFCGAL is a real hard to compile piece of software. Use it on qgis mean
> to
> > transformer the qgis in a real hard to compile software .
>
> cgal is packaged in all mayor OSs, AFAIK,
Paolo,
just to understand better :
what do you mena as "our target for QGIS"
?
I don't gind any page in QGIS site say-inf the targets OS .
Instead I see the download page will offer:
Ubuntu, Debian, Fedora, OpenSuse, RHEL (and various rhel like distro),
Mandriva, ArchLinux,
and ofcourse MAc, and
ject: Re: [Qgis-developer] Opinion on plugin named prepair (and possible
> likes)
>
> Hi Hugo,
>
> About a month ago, I created a formula for prepair in the OSGeo4Mac Homebrew
> tap [0,1].
>
> I would appreciate it if you would review it, and possibly do any pull
> req
dling.
Thanks,
Larry
> All the best,
> Ken
>
> *From:* Larry Shaffer
> *Date:* 6 juni 2014 17:30:53 CEST
> *To:* h.led...@tudelft.nl
> *Cc:* QGIS Developer List
> *Subject: Re: [Qgis-developer] Opinion on plugin named prepair (and
> possible likes)*
>
> H
Hi Larry,
Maybe I’m mistaken here, but doesn’t Homebrew always compile from source?
Because if so, I’d think that even the mostly statically linked binary would
still need to download and install a Boost bottle (albeit one that creates a
static version of the libraries).
But in any case, if it
Il 06/06/2014 20:03, Andrea Peri ha scritto:
> Paolo,
>
> just to understand better :
> what do you mena as "our target for QGIS"
I was wrong: in our qgis.org/debian-nightly repo there is qgis 2.3 for wheezy,
so
most probably 2.4 will be ready for it.
I was writing about official Debian packages
Il 06/06/2014 18:54, Larry Shaffer ha scritto:
> There are probably others; but, adding Boost into the QGIS source mix will be
> a large
> change, IMHO. I think it would ultimately be beneficial.
So, in short, pros seem much higher than cons, IMHO.
Anyone planning to do it?
All the best.
--
Pa
Hi Ken,
On Fri, Jun 6, 2014 at 12:46 PM, Ken Arroyo Ohori <
g.a.k.arroyooh...@tudelft.nl> wrote:
> Hi Larry,
>
> Maybe I’m mistaken here, but doesn’t Homebrew always compile from source?
> Because if so, I’d think that even the mostly statically linked binary
> would still need to download and in
Hello,
Would it be possible in any case to have the boost + CGAL dependencies
Optional ?
These two libraries are really long to compile, and can therefore slow down
the development workflow pretty hard.
As for having an internal boost / cgal source tree, there is a strong risk of
divergence bee
Vincent Picavet (ml) wrote
> QGIS dependencies begins to be really huge, and this complicates a lot
> compilation and deployment.
Hi, furthermore, user experience starts to be impacted on windows by all
those library links. First opening on windows is long. Adding other by
libraries will lead
29 matches
Mail list logo
