Re: [Gvsig_english] Problem installing gvSIG
> Hi Joaquin, > > Just out of curiosity, which is going to be the new installer toolkit? > > gvSIG 2.3 will come with another installer. > If nothing happens next build will come with the new installer basedon > IzPack. Nice! Thanks Joaquin. -- Cèsar Ordiñana Navarro DiSiD Corporation (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Problem installing gvSIG
> For the next version 2.3 we will use another installer that corrects > this problem. > > Sorry for my bad english > > A greeting > Joaquin > Hi Joaquin, Just out of curiosity, which is going to be the new installer toolkit? Regards, -- Cèsar Ordiñana Navarro DiSiD Corporation (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Google Summer of Code 2014 starts
El 07/02/14 08:35, Jorge Gaspar Sanz Salinas escribió: > Anne Ghisla and Hamish Bowman are again this year the coordinators for > the participation of the Open Source Geospatial Foundation (OSGeo) on > the Google Summer of Code (GSoC). > > Initial announcement: > > https://lists.osgeo.org/pipermail/discuss/2014-February/012710.html > > As usual, ideas are the first step for participating projects so feel > free to contribute to the 2014 gvSIG ideas page on the OSGeo wiki: > > http://wiki.osgeo.org/wiki/GvSIG_GSoC_2014_Ideas > > There are links to other years ideas pages for reference (and not > implemente ideas that can be reused). > > Best regards Thanks Jorge for keeping us up-to-date with the GSoC participation. I have added a proposal in the gvSIG ideas page about adding OpenCL support with Aparapi for Geoprocessing in gvSIG desktop. Feel free anybody to send any question or contribution to the proposal. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] About gvSIG project files formats (.gvp and .gvproj)
El 06/06/13 16:08, Antonio Falciano escribió: > Hi all, > I have three fundamental questions about the different project files > formats of gvSIG 1.x and gvSIG 2.0 versions: > 1) What are the main differences between the .gvp and .gvproj files? > 2) Will an "Import .gvp file" tool be developed in gvSIG 2.0? > 3) Why do .gvproj files seem to be more closed than .gvp ones? > Thanks in advance for your attention. > > Cheers, > Antonio Hi Antonio, 1) All of them, it is a new format based on XML Schema and new APIs to load and store persistence data. We had problems with the old format to maintain compatibility when gvSIG code changed, and the APIs where much harder to use. This format is used in other persistence files used in gvSIG 2.0: symbols, thematic maps, ... 2) It's in the TODO list, but don't know when. It won't be an easy task, at least to be able to restore all info of all gvSIG plugins in a project, but at least the most important things (layers, symbology, ...) I think could be loaded. 3) In reality its a zip file, just unzip it and will see a state.xml file, which is the real project file. The .gvproj file also contains the XML Schemas, and maybe other resources needed in the future, like the Open/LibreOffice file formats. I think the internal XML is easier to read/write/use, but I hope users won't need to edit it very often. Regards. -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Problem gvSIG 2.0.0.2066 -- How do I work with Multisurface3D Shapefiles?
Hi, Thanks to the work of Jorge Piera they are really based on the ISO 19107:2003 [1], which "specifies conceptual schemas for describing the spatial characteristics of geographic features". GML (ISO 19136:2007) [2] is a XML encoding compliant with the previous ISO, so geometry types are similar to gvSIG's. Regards. [1] http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=26012 [2] http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=32554 El 06/06/13 17:26, Jordi Torres escribió: Hi Fran, That names are based in the GML specification AFAIK. Cheers. 2013/6/6 Francisco Puga mailto:fp...@cartolab.es>> Hi Cesar, There is any reason to choose that names, surface and so on, instead the more common denominations? 2013/6/6 Simon Cropper mailto:simoncrop...@fossworkflowguides.com>>: > > Simon, would you be able to share the shapefile with us so we can try > > to find what is happening? > > I have I sent them to Joaquin del Cerro > > On 06/06/13 19:43, Cèsar Ordiñana wrote: >> El 06/06/13 10:44, Simon Cropper escribió: >>> Jukka, >>> >>> To be honest nor have I. >>> >>> This is what is reported in the gvSIG layer properties dialog. >> >> Hi, >> >> The MultiSurface3D type is the gvSIG geometry type name, not the Shape >> type name, as it is independent of the data source type. >> >> The relationship between gvSIG geometry types and the shapefile ones is, >> more or less: >> >> - Surface: Polygon >> - Curve: Polyline >> - Point: Point >> - 3D: Z >> - 2D: Nothing >> >> We share the prefix "Multi" and when we add support for geometries with >> "M" it will be added as a suffix also. >> >> So a Shape of Polyline type should become a Curve2D in gvSIG, a Shape of >> PolygonZ type must become a Surface3D, ... In the case of a MultiPatch >> Shape, maybe it would become a MultiSurface2D or MultiSurface3D, but I'm >> not sure if this is being taken into account in the current code. Anyway >> I suppose this is not the case of Simon's shape file, so it seems to me >> there is a bug in the information shown in the layer properties dialog. >> >> Simon, would you be able to share the shapefile with us so we can try to >> find what is happening? If I understood you well, the file is opened in >> gvSIG but the editing and geoprocessing tools don't work with it. Is >> that so? >> >> Regards. >> -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] (no subject)
El 06/06/13 11:14, Elisabet Adeva escribió: pls, errase me from the mailing list. thnks! Best Regards, Elisabet A. Diplomada en Geografía, UB ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional Hi Elisabet, You have the information to do it yourself at the end of all the mailing list emails. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Problem gvSIG 2.0.0.2066 -- How do I work with Multisurface3D Shapefiles?
El 06/06/13 10:44, Simon Cropper escribió: > Jukka, > > To be honest nor have I. > > This is what is reported in the gvSIG layer properties dialog. Hi, The MultiSurface3D type is the gvSIG geometry type name, not the Shape type name, as it is independent of the data source type. The relationship between gvSIG geometry types and the shapefile ones is, more or less: - Surface: Polygon - Curve: Polyline - Point: Point - 3D: Z - 2D: Nothing We share the prefix "Multi" and when we add support for geometries with "M" it will be added as a suffix also. So a Shape of Polyline type should become a Curve2D in gvSIG, a Shape of PolygonZ type must become a Surface3D, ... In the case of a MultiPatch Shape, maybe it would become a MultiSurface2D or MultiSurface3D, but I'm not sure if this is being taken into account in the current code. Anyway I suppose this is not the case of Simon's shape file, so it seems to me there is a bug in the information shown in the layer properties dialog. Simon, would you be able to share the shapefile with us so we can try to find what is happening? If I understood you well, the file is opened in gvSIG but the editing and geoprocessing tools don't work with it. Is that so? Regards. -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) > On 06/06/13 17:02, Rahkonen Jukka wrote: >> Antonio Falciano wrote: >> >> >>> Il 06/06/2013 06:40, Simon Cropper ha scritto: >>>> Hi Guys, >>>> >>>> Operating System: Ubuntu 13.04 (using Gnome Classic Interface). >>>> gvSIG Version 2.0.0.2066 >>>> Java version: 1.6.0_20 >>>> >>>> **PROBLEM** >>>> >>>> I have a "MultiSurface3D" ESRI shapefile. >>>> >>>> I have tried but can't seem to convert it to something that gvSIG can >>>> use properly. >>>> >>>> The file contains 7 polygons but I can't copy, update properly or use >>>> with the geoprocessing wizard. >>>> >>>> I have tried ogr2ogr -f "ESRI Shapefile" -nlt "POLYGON25D" >>>> ./POLYGON25D.shp ./Areas_3D.shp >>>> >>>> but this did not work. I suspect it is the Multisurface type rather >>>> than the 3D/2D issue, although this does not help. >>> Hi Simon, >>> have you tried with SEXTANTE "Remove3DM" tool? >>> >>> Cheers, >>> Antonio >> I have never heard about "MultiSurface3D" shapefile type. Has it something >> common with the "MultiPatch" type? What does ogrinfo report about your >> shapefile? >> >> -Jukka Rahkonen- >> ___ >> Gvsig_internacional mailing list >> Gvsig_internacional@listserv.gva.es >> >> To see the archives, edit your preferences or unsubscribe from this mailing >> list, please access this url: >> >> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG 2.0 and sextante?
El 04/06/13 18:52, Victor Olaya escribió: > Let me reword my phrase: > > It is sad that you decided to create your own API just because (as > Alvaro said), you didn't want anything created by the gvSIG > association to not be GPL. So instead, of contributing to SEXTANTE, > you wrote your own geoprocessing API and wrote your new geprocesses > for your API instead of directly for SEXTANTE. > > So, in the end, the reason why we do not have those geoprocesses in > the official SEXTANTE bindings is a matter of licenses, because, if > you were happy with the SEXTANTE license, I suppose you would have > contributed those new algorithms to SEXTANTE (as far as I understand, > the gvSIG project had no other reason for forking SEXTANTE than the > license issue, right?). There is already an app-specific package with > algorithms such as those ones, that only run on gvSIG and are not > generic, so that wouldn't be a problem > > Ideally, the changes you made for the new geoprocessing framework in > 2.0 should be on SEXTANTE, having new bindings for 2.0 (and maybe > other changes that could benefit other applications), but the lack of > understanding between both projects lead to this. And that lack of > understanding was caused by a license issue... > > I am not saying it is a bad thing, but that's how it all happened I agree with the lack of understanding, which is sad but that's how it is. But the gvSIG geoprocesses use many gvSIG 2.0 APIs, like the data access ones, that wouldn't have changed regardless of the license matter. And being gvSIG-only geoprocesses, I don't understand why they have to be contributed to sextante and can't remain in gvsig. Anyway, this discussion is based on guessing about what would have happened if things were different, so who knows... Regards. 2013/6/4 Cèsar Ordiñana : >> El 04/06/13 15:30, Victor Olaya escribió: >>> "On one hand, in order to improve the usability that we started in gvSIG >>> 2.0, we dealt with the option to have an unified geoprocessing manager, >>> where the user can find any geoprocess available in gvSIG. And our first >>> objective, from the point of view of the product, we had to include all >>> the geoprocessing tools of the gvSIG 1.x versions for the users. For >>> that, in gvSIG 2.0 you can find the geoprocessing tools from the "old" >>> gvSIG geoprocessing manager (clip, buffer, union...), the raster >>> geoprocesses of gvSIG, and the geoprocessing tools from the Sextante >>> library." >>> >>> I agree that this is a good thing, and it is sad that this development >>> was not incorporated to SEXTANTE just for a matter of licenses... >>> >>> Cheers >>> Victor >> Sorry but this is not true. Those geoprocesses use the gvSIG 2.0 APIs >> and wouldn't run on sextante alone, regardless of the license. >> >> Regards. >> -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG 2.0 and sextante?
> 2) gvSIG 2.0 has the SEXTANTE geoalgorithms available in the toolbox > (why they keep calling them "SEXTANTE algorithms" while they have > removed the SEXTANTE name and icon from the toolbox...i do not know, I > guess you should ask the gvSIG people). However, and as far as I have > seen, they use the algorithms unmodified, but put on top of modified > bindings. In other words, and as I have mentioned several times, gvSIG > 2.0 has the most recent algorithms, connected to a fork of the > SEXTANTE core. Modifications to the SEXTANTE core introduced ater this > fork was created (which was prior to our 1.0 version) are not > incorporated. I haven't had a real close look at the work done by the > gvSIG people on that, so I cannot say anything about the stability of > this mix... Let me clarify a bit about that "sextante fork" you are always complaining for. In gvSIG desktop 2.0 the sextante library is used the same way as all the many external libraries used in the project. When you install gvSIG desktop 2.0, the sextante library jar files, including the sextante geoalgorithms, the runtime and the user interface components are the same ones as the files we downloaded from the sextante project. We don't even compile them! And yes, we have our own gvSIG plugin to integrate the sextante library loosely based in the sextante plugin for gvSIG 1.x, but to call it a fork of the sextante core, at least for me its not fair. Even less taking into account we haven't touched a single line of the sextante library code. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG 2.0 and sextante?
El 04/06/13 15:30, Victor Olaya escribió: > "On one hand, in order to improve the usability that we started in gvSIG > 2.0, we dealt with the option to have an unified geoprocessing manager, > where the user can find any geoprocess available in gvSIG. And our first > objective, from the point of view of the product, we had to include all > the geoprocessing tools of the gvSIG 1.x versions for the users. For > that, in gvSIG 2.0 you can find the geoprocessing tools from the "old" > gvSIG geoprocessing manager (clip, buffer, union...), the raster > geoprocesses of gvSIG, and the geoprocessing tools from the Sextante > library." > > I agree that this is a good thing, and it is sad that this development > was not incorporated to SEXTANTE just for a matter of licenses... > > Cheers > Victor Sorry but this is not true. Those geoprocesses use the gvSIG 2.0 APIs and wouldn't run on sextante alone, regardless of the license. Regards. -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Problem gvSIG 2.0.0.2066 -- Program crashes when opening ECW file
El 22/05/13 12:35, Cèsar Ordiñana escribió: > El 22/05/13 11:52, Simon Cropper escribió: >> On 22/05/13 18:56, Cèsar Ordiñana wrote: >>> export NCS_USER_PREFS=/tmp/dummy >> I did what you said, click... click, open... >> >> A smile spreads across my face... :) >> >> Yes, it worked. >> >> Thank you Cèsar > Great! I have added all the info to the issue ticket [#1695], for this > to be taken into account in the following gvSIG release. > > Also, I have not tried it, but I suppose the same trick would work for > gvSIG 1.11 or 1.12. The launcher script is not the same as the one used > in gvSIG 2.0, but the "export ..." line may be included anywhere in the > script before the java execution, for example in the first line. > > Regards, > > [#1695] https://devel.gvsig.org/redmine/issues/1695 > Confirmed, gvSIG 1.11 and 1.12 share the same problem and the same solution. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Problem gvSIG 2.0.0.2066 -- Program crashes when opening ECW file
El 22/05/13 13:53, Nacho Uve escribió:
0_0
Is that NCS_USER_PREFS export need on 32bits? Or can it be included
safely on the script anyway?
Regards,
Nacho V
2013/5/22 Cèsar Ordiñana <mailto:cordiny...@gvsig.com>>
El 22/05/13 11:52, Simon Cropper escribió:
> On 22/05/13 18:56, Cèsar Ordiñana wrote:
>> export NCS_USER_PREFS=/tmp/dummy
> I did what you said, click... click, open...
>
> A smile spreads across my face... :)
>
> Yes, it worked.
>
> Thank you Cèsar
Great! I have added all the info to the issue ticket [#1695], for this
to be taken into account in the following gvSIG release.
Also, I have not tried it, but I suppose the same trick would work for
gvSIG 1.11 or 1.12. The launcher script is not the same as the one
used
in gvSIG 2.0, but the "export ..." line may be included anywhere
in the
script before the java execution, for example in the first line.
Regards,
[#1695] https://devel.gvsig.org/redmine/issues/1695
Hi Nacho,
I think it is not related to the 32/64 bits issue, in any case you can
include the "export" line safely. It seems that environment variable is
the path of a configuration file used by the ecw library, and you don't
need to create it.
Also, if you want to use the library's internal default value, you can
change the line to:
export NCS_USER_PREFS=${HOME}/.erm/ncsuserprefs.xml
Regards,
--
Cèsar Ordiñana Navarro
gvSIG software architect
DiSiD Technologies (http://www.disid.com)
___
Gvsig_internacional mailing list
Gvsig_internacional@listserv.gva.es
To see the archives, edit your preferences or unsubscribe from this mailing
list, please access this url:
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Problem gvSIG 2.0.0.2066 -- Program crashes when opening ECW file
El 22/05/13 11:52, Simon Cropper escribió: > On 22/05/13 18:56, Cèsar Ordiñana wrote: >> export NCS_USER_PREFS=/tmp/dummy > I did what you said, click... click, open... > > A smile spreads across my face... :) > > Yes, it worked. > > Thank you Cèsar Great! I have added all the info to the issue ticket [#1695], for this to be taken into account in the following gvSIG release. Also, I have not tried it, but I suppose the same trick would work for gvSIG 1.11 or 1.12. The launcher script is not the same as the one used in gvSIG 2.0, but the "export ..." line may be included anywhere in the script before the java execution, for example in the first line. Regards, [#1695] https://devel.gvsig.org/redmine/issues/1695 -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Problem gvSIG 2.0.0.2066 -- Program crashes when opening ECW file
Hi Simon, I think we have found a temporary solution. It seems the crash is produced because of a bug in the native library we use to load the ECW files. I've been looking and it is also happening in the last linux distributions when you use gdal to open an ECW file: http://osgeo-org.1560.x6.nabble.com/ECW-support-on-Fedora-Linux-error-td4991388.html One of the developers on that discussion found a very easy way to avoid the problem, by setting the environment variable NCS_USER_PREFS to point to some bogus file name. I have just updated to Ubuntu 13.04 and had the same crash opening ECW files, but by setting the environment variable it works again. If you want to try it just edit the "gvSIG.sh" file in your gvSIG 2.0 installation, go to the line 144 (after the "export LC_NUMERIC=C") and add a new line with the following text: export NCS_USER_PREFS=/tmp/dummy Then save the file and run gvSIG to check if it works for you. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) El 22/05/13 10:29, Simon Cropper escribió: > Pau Aragó Galindo, > > Can you extract the commands you used from your ".bash_history" file in > your home directory. None of the tutorials mentioned actually list > commands that correct the problem! > > If you have solved the issue, knowing what you did would be helpful. > > Thanks > > On 22/05/13 17:32, Pau Aragó wrote: >> Hello; >> >> You can install 32 bits libraries ] in ubuntu to work properly with >> gvSIG. At least works for me. >> >> https://help.ubuntu.com/community/32bit_and_64bit >> >> >> 2013/5/22 Simon Cropper > <mailto:simoncrop...@fossworkflowguides.com>> >> >> Antonio, >> >> Yes, I saw a few bug reports in Spanish. It was unclear what the status >> was of these reports. >> >> It does not help however that none of my Linux based versions of gvSIG >> work and that I have to use a 5-year old virtual machine with an >> outdated XP version with a outdated gvSIG to see the raster data. >> >> Do I assume that this issue is not being worked on and I should >> investigate alternative fosGIS solutions or can anyone help nut out what >> is going on? >> >> On 22/05/13 16:52, Antonio Falciano wrote: >> > Il 22/05/2013 08:31, Simon Cropper ha scritto: >> >> Hi Guys, >> >> >> >> Operating System: Ubuntu 13.04 (64 bit). >> >> gvSIG Version 2.0.0.2066 >> >> Java version: 1.6.0_20 >> >> >> >> **PROBLEM** >> >> >> >> When I try and open an ECW file from a fresh install of gvSIG it >> crashes. >> >> >> >> The ECW file is not corrupt as I can open it using an old version of >> >> gvSIG on Windows (in VirtualBox!). >> >> >> >> During the install I noted the installation package indicated >> that it >> >> installed the ECW support plug-in. I can see the file but >> selecting it >> >> causes the java VM to disappear. gvSIG records no errors. >> >> >> >> It has not help reinstalling gvSIG with a new install of Java. >> >> >> >> Any suggestions? I have searched the Internet but nothing >> obvious except >> >> recommendations to use Java in 32 bit mode not 64 bit mode. The >> attached >> >> report shows that java started in 32 bit mode. >> >> >> >> I have also attempted to use Version 1.10, 1.11 and 1.12 but >> none work. >> >> >> >> *command line output* >> >> >> >> http://www.fossworkflowguides.com/pap/files/CL_Output.txt >> > >> > Hi Simon, >> > thank you for reporting this issue. It seems that it was already >> > reported in the bug tracker [#1695] with a very similar configuration >> > and it's still open. >> > I'm Italian and so I understand quite well written Spanish, but >> others? >> > So I think that it would be better to write tickets in the bug >> tracker >> > in English. IMHO full internationalization of gvSIG projects >> passes through >> > this little details and it's very important for the chances of gvSIG >> > project. >> > >> > Cheers, >> > Antonio >> > >> > [#1695] https://devel.gvsig.org/redmine/issues/1695 >> > ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG and gvSIG-CE, when will someone clarify the situation?
El 02/08/12 11:11, Ruth Schönbuchner escribió: Dear Cèsar, list, regarding this issue in having effort for testing, translations, spreading... i want to add that José and me put a lot of effort in spreading gvSIG in Germany! For many years, we put our time and effort in doing presentations, workshops on the different conferences like AGIT, FossGIS or Intergeo. We found a bugs that are well documented and we also work hard in trying to fix them to improve the software and we send the patches to you to improve gvSIG! It would be impossible to work in real terms without local committers (gvSIG has zero committers outside Spain). Changing gvSIG CE to another name would complicate this exchange. Personally I would prefer to discuss on how to improve the software and on how to improve contribution between gvSIG Association and non-members. Maybe we can find a way? Hi Ruth. I really appreciate all the effort you have done and I know you keep carrying on, I don't have any doubt about that. But I don't agree with you in the need to create a separate project fork to be able to contribute. I'm sure the process might be improved, but it is already defined how to contribute in the project, be it with code, documentation, translations, etc. You have all the needed documentation in the gvsig.org website. Of course any comments about it are wellcome. In any case, gvSIG being an open source project, anyone is free to create a fork. I don't have any problems with that and the gvSIG CE existence. But this discussion is about the name, which is generating a lot of confusion between users. Regards. -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG and gvSIG-CE, when will someone clarify the situation?
El 02/08/12 10:06, José Antonio Canalejo Alonso escribió: >Hello José Antonio. >As a former member of the gvSIG Association, its hard for me to believe you didn't know about the trademark beforehand. You should trust the community, Cesar. Even though they aren't former member of *your* Organization. People who have been working hard for gvSIG before you came to this project. I can't understand why you insist talking as if you where some type of community representative or whatever, trying to put some type of barrier between the gvSIG Association members and *your* idea of community. Or do you mean Association members don't belong to the community and haven't been working hard for gvSIG for a long time? I'm starting to believe you think using the word "community" in your project name makes it automatically being endorsed by all the gvSIG community, but please, come down to reality. Regards. -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG and gvSIG-CE, when will someone clarify the situation?
El 01/08/12 17:09, José Antonio Canalejo Alonso escribió: Hello Jorge, gvSIG was born without trademarks [1]. The owners of the copyright are now different than the ones at the beginning of the project. Things have changed a lot since the gvSIG incubator application request was sent to OSGeo [1]. This link should be actualized and the actual situation of gvSIG should be new exposed: names of all official committers, relationships with commercial companies or products, patents, trademarks, copyright, people actively contribute (code, documentation, other?), actual sponsors, etc These changes about trademarks were never notified in this list. My apologies if the name of the project is creating confusion. gvSIG CE was created as many other projects with the name of gvSIG. After the creation of gvSIG CE, we were informed about the existing trademarks. Hello José Antonio. As a former member of the gvSIG Association, its hard for me to believe you didn't know about the trademark beforehand. And those many other projects you talk about are mainly extensions and customizations of the gvSIG project, not complete forks. In any case, I think its never late to rename the project, or is it written in stone? Instead of starting any expensive and painful legal action, we should keep on working, producing good code like we are making now. Developers from gvSIG EIEL and gvSIG CE made important contributions to gvSIG 1.10, 1.11 and 1.12. Let's keep working together in different repositories. We are more effective and faster now than following the official procedures. More contributions will come from gvSIG CE Team to gvSIG 1x. Otherwise, you have announced, the gvSIG Association will invest its resources in gvSIG 2x. Let us then develop in peace gvSIG 1x. and integrate SEXTANTE there as it should be done. No matter of we are official or not. Do not try to make official a community, this will never work. Best regards! Jose I don't know what you are talking about. First of all you mention gvSIG EIEL developers like having something to do with the gvSIG CE project or not related to the gvSIG project. But the gvSIG EIEL project is a gvSIG official one, the organizations that develop and promote it are members or collaborate with the gvSIG Association, and some of the developers are maintainers of the gvSIG official code or even belong to the gvSIG TSC board. Of course they contribute to gvSIG, they are PART of it. You also mention a gvSIG Association announcement about investing its resources in gvSIG 2. But, who do you think is investing in gvSIG 1.12? I really appreciate the patches you are submitting, but it has nothing to do with all the effort involved developing gvSIG 1.12, as well as the work made by non developers: testing, translations, user manual, spreading, etc. All of this of course with the help and support of the gvSIG community. And finally, could you please explain what are those procedures you talk about and why they are so slow and ineffective? You talk about having to sign a CLA, sending patches in tickets and being reviewed by the maintainers? Those and any other procedures are there for a reason. Many of the big and successful open source projects have procedures, usually much more stricter than the gvSIG ones. Take a look, for example, at projects like the linux kernel, eclipse, android, etc. to see what I'm talking about. In any case, you are free to have the code wherever you want. But please try not to confuse the gvSIG users as much as possible, and let us develope gvSIG 1x, 2x, ... whatever in peace. Regards. -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Bug reporting, 3D extension
Hi all, I would like to advise everybody to wait a bit until all the projects and trackers are available and ready in the new servers. This is still a work in progress, so there are still some things to configure and prepare, and what you can see now in the redmine service might change before it is ready. Although I'm not in charge of this configuration, I'm going to try to clarify some things: - The correct URL for the server is https://devel.gvsig.org/redmine . The gvsig-devel.gva.es name is pointing now to the same IP address as the other one, but it won't be maintained in the future, so please don't use it. - There is only ONE tracker for all the bugs and feature requests, the gvsig-desktop one: https://devel.gvsig.org/redmine/projects/gvsig-desktop That tracker will be open, so you will be able to create new requests as anonymous (I think it is already open). All the other projects available into the redmine service are used to manage development tasks for the project, not to create bugs or feature requests. In any case, take into account this is still being configured so it might change when the service is ready and released officially. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) El 30/12/11 16:34, Francisco Puga escribió: > I think that there is a misunderstanding here. > > The new bug tracker needs the user to register himself and then to be > approved by the admin of the site. I agree with Jonathan that is > better if the user can report bugs after the register without have to > wait for the admin approbation. > > Once a week or something like that the admin can remove the "spam > registrations". But as Jorge said i don't know how much time will cost > this approach. > > El día 30 de diciembre de 2011 13:24, Francisco José Peñarrubia > escribió: >> I think mailing lists is different from bug reporting. >> That said, I think bug tracker can be open (not registration required), and >> see if we receive too many bad tickets (I mean poor documented and so on). >> If so, ask for registration. >> >> On the other side, I would recommend to register if you are really >> interested, because you will receive information about how the bug is >> corrected. Or it can be a point of contact with the developer to ask for >> clarifications, and so on. >> >> My two cents on this. >> >> Best regards, and Happy New Year for all!!. >> >> Fran. >> >> El 30/12/2011 13:12, jonathanmou...@warwickshire.gov.uk escribió: >> >>> I don't agree. If we want quality bug files we expect people at least >>> taking the effort to register themselves, it's IMHO a minimum >>> requirement. Another example, if you would see the amount of spam >>> subscription requests to this mailing list we receive every week you >>> would understand why we need to moderate it. >> I disagree with this point quite strongly, partially for idealogical reasons >> (I think if you a project that makes it hard to report bugs is blinkering >> itself), but also for practical ones. Registration is no filter for quality >> content - just look at some youtube comments for an example of that. What it >> will filter is the people who wanted to report a bug they just found but >> aren't interested enough in the software to remember what the bug is and >> exactly how to replicate it when their subscription request arrives however >> many hours later. I know there are lots of bugs in various projects I >> wouldn't have reported if I'd not been able to do so immediately (and as >> mentioned previously, many I didn't report for just that reason). >> >> As to spam list-subscription requests - I can understand why you'd moderate >> this, but at the same time, of the other lists I've been on recently (i.e. >> QGIS-user, geoserver, geonetwork), they don't appear to have moderation on >> subscription but still don't get spam to the list. Not sure how they're >> doing that. >> >> The other advantage to doing away with subscriber moderation is it's one >> less thing for the devs to do. >> >> Just a thought. >> >> Jonathan >> >> >> >> From:Jorge Gaspar Sanz Salinas >> To:gvsig_internacional@listserv.gva.es >> Date:30/12/2011 10:07 >> Subject:Re: [Gvsig_english] Bug reporting, 3D extension >> Sent by:gvsig_internacional-boun...@listserv.gva.es >> >> >> >> >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >>
Re: [Gvsig_english] Pl help Network analysis
El 13/12/11 03:41, Ravi escribió: installed gvSIG 2.0.0, but donot find Network analysis menu. Using MS XP Even in the last Version of gvSIG also same result. No Network analysis menus. Do I need to install any plugins to have Network analysis support Ravi Hi Ravi, Sorry but the network analysis support plugins are still not available for the gvSIG 2.0.0 version. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es To see the archives, edit your preferences or unsubscribe from this mailing list, please access this url: http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Build error developing gvSIG 2.0
Thanks Jordi!! From the build log information it seems the "version" property of the package.info file is not being parsed and is read as null. I haven't been able to reproduce the error, but it seems there is an uncovered case here. Maybe the package.info for the org.gvsig.coreplugin plugin was previously generated with errors and the parser wasn't able to load it, reading a null for the version property. Anyway, just in case I have added a null check, so at least it doesn't fail next time. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) El 03/10/11 10:27, Jordi Torres escribió: Hi Cesar, I just discovered that removing the folder extensions in build/product/ is enough to compile the sources succesful. Cheers. 2011/10/3 Jordi Torres <mailto:jtorresfa...@gmail.com>> Hi Cesar, I am getting this error again. I ran maven with -e option. This is the error in the build log: [INFO] Generating the package info for the plugin: org.gvsig.coreplugin with the following information: [INFO] Plugin name: Skin management framework [INFO] Plugin description: This is the extension that provide the basic skin to gvsig [INFO] Plugin version: 2.0-SNAPSHOT [INFO] Plugin build number: 2035 [INFO] Plugin state: devel [INFO] Plugin official: true [INFO] Plugin operatingSystem: all [INFO] Plugin architecture: all [INFO] Plugin javaVM: j1_5 [INFO] Plugin gvSIGVersion: 2.0.0 [INFO] gvSIG Plugin's folder: /home/jtorres/Projects/GIS/gvSIG/gvSIG-2.0/gvsig-sources/libCorePlugin/../build/product/gvSIG/extensiones [INFO] Package info folder: /home/jtorres/Projects/GIS/gvSIG/gvSIG-2.0/gvsig-sources/libCorePlugin [INFO] Dependencies: null log4j:WARN No appenders could be found for logger (org.gvsig.tools.util.impl.DefaultServiceLoader). log4j:WARN Please initialize the log4j system properly. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error getting a MakePluginPackageService for the plugin folder: /home/jtorres/Projects/GIS/gvSIG/gvSIG-2.0/gvsig-sources/libCorePlugin/../build/product/gvSIG/extensiones Embedded error: Exception creating the installer service to create installers [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error getting a MakePluginPackageService for the plugin folder: /home/jtorres/Projects/GIS/gvSIG/gvSIG-2.0/gvsig-sources/libCorePlugin/../build/product/gvSIG/extensiones at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error getting a MakePluginPackageService for the plugin folder: /home/jtorres/Projects/GIS/gvSIG/gvSIG-2.0/gvsig-sources/libCorePlugin/../build/product/gvSIG/extensiones at org.gvsig.installer.maven.GeneratePackageInfoMojo.execute(GeneratePackageInfoMojo.java:264) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(De
Re: [Gvsig_english] Build error developing gvSIG 2.0
El 26/09/11 10:20, Jordi Torres escribió:
Hi Cesar,
Thanks for your quick answer.
When I say "update the sources" I refer to svn up in gvSIG 2.0
sources. I am running maven in the console, and it is when compiling
gvSIG 2.0, not my project. Jesus and me are experiencing the same problem
when we update the gvSIG 2.0 sources. When we clean the project we can
compile it all, but is a little time-consuming task.
Correct me if I am wrong, Is not error stack trace (-e option)
activated by default? Anyway next time I get the error I will paste
the build log.
Hi Jordi,
No, the -e option is not activated by default in maven. I don't know
why, because it is a very useful information, maybe it is too much
verbose in some cases. I enabled it by default in the launchers provided
to integrate maven in eclipse for the gvSIG projects, I think it is
worth it.
Regards,
--
Cèsar Ordiñana Navarro
gvSIG software architect
DiSiD Technologies (http://www.disid.com)
Thank you again.
El 26 de septiembre de 2011 10:10, Cèsar Ordiñana
mailto:cordiny...@gvsig.com>> escribió:
El 26/09/11 09:54, Jordi Torres escribió:
> Hi all,
>
> I am getting a strange build error every time I update the sources,
> the error is:
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error getting a MakePluginPackageService for the plugin
> folder: {**}../build/product/gvSIG/extensiones
>
> Embedded error: Exception creating the installer service to create
> installers
>
> Any clue?
Hi Jordi,
Could you explain a bit more what you mean with "update the sources"?
Maybe you are using the eclipse maven plugin, or running maven in the
process?
It seems an error related with our installer maven plugin. Could
you run
maven in your project with stack traces enabled and attach the result?
(mvn -e install)
Regards,
--
Cèsar Ordiñana Navarro
gvSIG software architect
DiSiD Technologies (http://www.disid.com)
>
> Thanks.
>
> --
> Jordi Torres Fabra
>
> gvSIG 3D blog
> http://gvsig3d.blogspot.com
> Instituto de Automática e Informática Industrial
> http://www.ai2.upv.es
>
___
Gvsig_internacional mailing list
Gvsig_internacional@listserv.gva.es
<mailto:Gvsig_internacional@listserv.gva.es>
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
--
Jordi Torres Fabra
gvSIG 3D blog
http://gvsig3d.blogspot.com
Instituto de Automática e Informática Industrial
http://www.ai2.upv.es
___
Gvsig_internacional mailing list
Gvsig_internacional@listserv.gva.es
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Build error developing gvSIG 2.0
El 26/09/11 09:54, Jordi Torres escribió:
> Hi all,
>
> I am getting a strange build error every time I update the sources,
> the error is:
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error getting a MakePluginPackageService for the plugin
> folder: {**}../build/product/gvSIG/extensiones
>
> Embedded error: Exception creating the installer service to create
> installers
>
> Any clue?
Hi Jordi,
Could you explain a bit more what you mean with "update the sources"?
Maybe you are using the eclipse maven plugin, or running maven in the
process?
It seems an error related with our installer maven plugin. Could you run
maven in your project with stack traces enabled and attach the result?
(mvn -e install)
Regards,
--
Cèsar Ordiñana Navarro
gvSIG software architect
DiSiD Technologies (http://www.disid.com)
>
> Thanks.
>
> --
> Jordi Torres Fabra
>
> gvSIG 3D blog
> http://gvsig3d.blogspot.com
> Instituto de Automática e Informática Industrial
> http://www.ai2.upv.es
>
___
Gvsig_internacional mailing list
Gvsig_internacional@listserv.gva.es
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Problem install language pack
El 17/08/11 09:52, Khoem Sokhem escribió: On 17 2011 14:12, Cèsar Ordiñana wrote: El 17/08/11 06:36, Khoem Sokhem escribió: Hello All, I have finished translating gvSIG into Khmer and at the moment I am also translating manual into Khmer. Currently, I have problem with installing language pack for Khmer in gvSIG 1.11 in Ms Windows 7, after installation I go to Window menu -> Preference -> General -> Language -> Install, and then I got the error message said that "Unable to install locales from the imported file : C:\Users\khem\Desktop\gvSIG_1_10_0-language-v1-km.zip" Does anyone have any idea for this issue? Welcome any idea! Thanks, Sokhem Hi Khoem, Please, send us the gvSIG log file and we will take a look at it. It is located into your user windows folder, in the gvSIG/gvSIG.log file. Also, it would be very useful if you could send us the language pack so we could make tests with it. Thanks in advance. Hello Cèsar, Please kindly check gvSIG.log and language pack files attached. Thank you very much for your help. I hope this problem will be fixed soon. Regards, Sokhem Hi Sokhem, I could successfully install the language pack in linux, so it seems the problem is not there. Looking at the log file, I have seen the following message: Caused by: java.io.FileNotFoundException: gvSIG\extensiones\com.iver.cit.gvsig\text_km.properties (Access is denied) At first sight it seems a permissions problem. Is your windows user able to modify files in the gvSIG installation folder? Maybe you installed it as administrator. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Problem install language pack
El 17/08/11 06:36, Khoem Sokhem escribió: Hello All, I have finished translating gvSIG into Khmer and at the moment I am also translating manual into Khmer. Currently, I have problem with installing language pack for Khmer in gvSIG 1.11 in Ms Windows 7, after installation I go to Window menu -> Preference -> General -> Language -> Install, and then I got the error message said that "Unable to install locales from the imported file : C:\Users\khem\Desktop\gvSIG_1_10_0-language-v1-km.zip" Does anyone have any idea for this issue? Welcome any idea! Thanks, Sokhem Hi Khoem, Please, send us the gvSIG log file and we will take a look at it. It is located into your user windows folder, in the gvSIG/gvSIG.log file. Also, it would be very useful if you could send us the language pack so we could make tests with it. Thanks in advance. -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Error building Gvsig 2.0: The plugin 'org.gvsig:org.gvsig.installer.maven' does not exist or no valid version could be found
El 03/06/11 12:07, G. Allegri escribió: > I'm not an expert with maven, please forgive my question which > probably is "for dummy". > > I'm setting up the build environment for Gvsig 2.0. > While running the ant tast from the build project, during mvn install > I get the error: > 'The plugin 'org.gvsig:org.gvsig.installer.maven' does not exist or no > valid version could be found' > > I see that the repository contains it [1], why does it appear > unaligned to maven? Hi Giovanni, I'm not sure what is happenning with that error, but it is happening to other people also. We will try to create a new workspace from scratch to try to reproduce and solve that problem. In the meanwhile, perform a 'mvn install' of the "org.gvsig.installer" project, and try again the 'mvn install' of all the projects. That way I think it will work again. > Thanks, > Giovanni > > [1] > http://gvsig-desktop.forge.osor.eu/downloads/pub/projects/gvSIG-desktop/maven-repository/org/gvsig/org.gvsig.installer.maven/ Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG and quick information: error message appears in gvSIG 1.11
El 31/05/11 13:56, Cèsar Ordiñana escribió: > El 31/05/11 13:18, Wolfgang Qual escribió: >> Dear Javi, >> >> could you also add the other issue described by Cesar and me to the >> bugtracker? Or should I do this? >> >> Best, >> Wolfgang >> >> -- >> View this message in context: >> http://osgeo-org.1803224.n2.nabble.com/gvSIG-and-quick-information-error-message-appears-in-gvSIG-1-11-tp6419147p6422301.html > Hi Wolfgang, > > I'm going to open the ticket by myself and include the information about > the two related bugs. > > Regards. > Done!: https://forge.osor.eu/tracker/index.php?func=detail&aid=15389&group_id=89&atid=732 Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG and quick information: error message appears in gvSIG 1.11
El 31/05/11 13:18, Wolfgang Qual escribió: > Dear Javi, > > could you also add the other issue described by Cesar and me to the > bugtracker? Or should I do this? > > Best, > Wolfgang > > -- > View this message in context: > http://osgeo-org.1803224.n2.nabble.com/gvSIG-and-quick-information-error-message-appears-in-gvSIG-1-11-tp6419147p6422301.html Hi Wolfgang, I'm going to open the ticket by myself and include the information about the two related bugs. Regards. -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG and quick information: error message appears in gvSIG 1.11
El 31/05/11 12:27, Wolfgang Qual escribió: > Dear Javi, > dear all, > > this effect can be observed in gvSIG 1.10 and 1.11. > And: the number of files is growing very much, if "quick info" is activated. > With only one layer in the view (without quick info: 660 files, quick info > activated: 930!). > > What is the opinion of the developers regarding this behaviour? A bug? > Possibly a possibility to optimize the > performance of gvSIG! > > Best, > Wolfgang Hi Wolfgang, Wow! that quick info behavior is really surprising. I think it is a bug, not sure if it is the same bug as the one found by Javi, but for sure creates the same problem. I'm going to include it into the same bug ticket so any developer who takes care of it has all available information. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG and quick information: error message appears in gvSIG 1.11
El 31/05/11 10:51, Javier Estévez escribió: > Hi, > > I'm not sure if this is related to Wolfgang's problem, but there may > be a issue with file management in gvSIG. It's easy to test, using > lsof command combined with wc to get open files: lsof -p pid | wc -l > (where pid is gvSIG's process identifier). > > - gvSIG with one view and one layer on it: 674 open files. > - remove that layer from the view (this layer is not being used anymore): 673 > - add the same layer: 676 > - remove it again: 675 > - and so on... > > It seems that every time we add a layer in gvSIG (I'm always talking > about shp), it opens 3 files (I assume they are shp, shx and dbf), but > two of them are never closed. If you work with a lot of shapes, sooner > or later you'll get a "Too many open files" error. One of our projects > has 35 shape files loaded at once and it works well, but we can't > perform some processes without getting the error... > > Best, > Javi Hi Javi, Thanks for your comments about this issue!! I think you have traced very well the problem (or one of them) and I agree with you that it seems there is a bug in the SHP data provider, not closing all opened files. I'm going to create a new bug ticket in the gvsig-desktop tracker, using your information and Wolfgang's. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] differences foe developers between gvsig 1.11 and gvsig 2?
El 23/05/11 12:54, G. Allegri escribió: > I'm evaluating the possibility to develop an extension for gvsig. It > will take a while to be completed so I was wondering wether to > implement it on the actual release (gvsig 1.11) or the next one... > 1.12, or 2? > I know that many changes and improvements are being made to the > extensions mechanism, and in general to the various APIs. Some of them > have been merged, but I don't know the APIs enough yet to easily > understand if my extension would be affected by the changes in the > next future. > Could you help me to resume the status of the cahnges going on and if > there is a release rodmap for gvisg 2? In short, should I work on 1.11 > or 2 APIs? > Thanks, > Giovanni Hi Giovanni, gvSIG 2.0 has just started the stabilization process, and our plan is to release it in september. The APIs have been freezed since some time ago, so you can develep with it now if you can wait to september, your plugin should not be affected by API changes in the meanwhile. If you can't wait or need any of the plugins that won't be initially available when gvSIG 2.0 is released, you can develop for the 1.11 version. It also should not be affected when the 1.12 becomes available, as only corrections and new functionalities are allowed, not API changes (unless absolutely needed). If you work with the 1.x APIs, you will have to make changes if you migrate it to the 2.0. How many will depend on which APIs you use, for example data access and persistence are new, but user interface related ones haven't changed much. If you already plan to do so, we have made a list of things to help in the migration: http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/howto-migrate-projects-to-gvsig-2-0 I would like to invite anyone who is or will migrate a plugin to gvSIG 2.0 to share with us any instructions or tips he has used in the process so we can enrich the migration document. Regards. -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG and quick information: error message appears in gvSIG 1.11
El 30/05/11 15:32, Wolfgang Qual escribió: > Dear list, > > I activated the quick-info-function for my shapefile "referate" and it > worked well. However, > a strange error message pops up, every time the cursor is moved. Error > message in the logfile: ... > And I had to realize that it is not possible to edit this layer anymore, > new error message: > > in a driver: gvSIG shp driver > Can´t find file: /opt/uis/proj/referate/referate.shp > in a driver: gvSIG shp driver > at ... > Caused by: java.io.FileNotFoundException: > /opt/uis/proj/referate/referate.shp (Too many open files) > at java.io.FileInputStream.open(Native Method) > at java.io.FileInputStream.(Unknown Source) > at > com.iver.cit.gvsig.fmap.drivers.shp.IndexedShpDriver.open(IndexedShpDriver.java:159) > ... 14 more > DEBUG AWT-EventQueue-1 com.iver.core.mdiManager.NewSkin - Activando > Information console > > I really do not understand this message: What does "Too many open files" > mean? I only opened 3 layers in the current view. > > Any ideas would be great! > Best, > Wolfgang Hi Wolfgang, You have hit the system or shell file handles limit. Look at this search for explanations and solutions about the problem: http://www.google.com/search?client=ubuntu&channel=fs&q=linux+Too+many+open+files&ie=utf-8&oe=utf-8 This is related to the system, as the number of files (including sockets and other system handles) is limited globaly or per user. But it may be a gvsig problem if files or remote connections are not closed when not used anymore, or remain opened when not really needed. - Let me ask you some questions to try to know how how reached the opened files limit: - Do you have a gvsig project with a lot (I mean hundreds if not thousands) of layers? Or many gvsig instances? - Are you using other programs at the same time as gvsig? - Could you send us how many files opened has the gvsig process? To obtain it, for example in gnome, open the system monitor , right-click on the gvSIG java process and select the "show open files" menu option (it may take a while). Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Call for Mac Community contributors.
El 26/05/11 14:42, Jordi Torres escribió: Just for curiosity, why is needed that approach in MacOSX? Is there any problems in the gvSIG JNI libraries? The answer is that we do not have the binaires necessaries to execute the jniCall. they are: libNCSEcw.so libNCSUtil.so libNCSEcwC.so libNCScnet.so As far as I know they are propietary, and they never gave us the binaries compiled for Mac O.S. at least for OSX series. Oh, I though gdal was using those same libraries to be able to open ecw files. Do you know if gdal is supporting that format by itself? For gvSIG 2.0, we will need more testing but I think we currently support that one format might be supported by many different providers, so the user is allowed to select which one to use. For example, in linux when the user opens an ecw file, he could select if he wants to open it through gdal or the current direct provider. For mac, if the direct one does not work, it would not be included in the installation. You know, I am a hooligan of the new DAL library! :). That way we could have both approaches in the main branch. Well, in that case not even in the gvsig-desktop svn repo, as from gvsig 2.0 onwards, the raster support has its own OSOR project and repository where you could work also. Yes, good point, and for gvSIG 2.x I am fully supporting to integrate as best as possible O.S. dependent code. But not for gvSIG 1.x. No, I think it would be much more difficult in gvSIG 1.x :( . And the UI changes, I think the main problem is related to panels which use absolute positioning, instead of relative positioning using any of the available standard swing layouts. If those panels are updated, I think that would solve another problem we have when the Look & Feel is changed, as I think it is the same problem you might have in macOSX. If we were lucky and that would be the case, we could use the new Nimbus L&F, much more interesting IMHO. Yes, we did the job with docking skin, but unfortunately there are many dialogs in gvSIG that needs changes to work with it. And if that is not the case, and branching is the only way to go, as I said you could use the gvsig-desktop project repository also, I think it will make life easier for you. I said it at the beginning, to work in gvsig-desktop repository is not a problem, but we need the appropiate permissions. Rafa and you are already commiters in gvsig-desktop, so no problem in that case, but if there are other volunteers out of the project, they will need to ask for it. Now I will leave others talk, as I don't want to monopolize the conversation.. ;) Ups, sorry Jordi, tell me something about the gdal ecw support, please. ;) Cheers. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Call for Mac Community contributors.
El 26/05/11 11:00, Jordi Torres escribió: Hi Jorge, Joaquin, and Manuel: We've been discussing here Manuel, Joaquín and me and well, we think your approach is not the best way to improve the gvSIG code. When one needs to do changes or improvements on the code branching should be the last resource as you are taking the decision of work aside the rest of the developments, aren't you? IMHO it is more reasonable to try to improve the current code for everyone and maybe do some work to plug your work on a separate extension if it's only for the Mac distro. There are points where I cannot see a way, for example when loading ecw layers. At this moment we are using Gdal plugin to load this layers. gvSIG for linux and win uses a shared library present in the code. How would you face this problem? In the other side the ui changes could be sensible in other platforms, beacuse it could imply some dialog type changes. I am not supporting to branch the whole gvSIG, only a few projects, where the code is sensible to have impact over the other distributions. About the use of gdal to load ecw, mrsids and others, it would be great to use it instead of the ecw or mrsid libraries directly for all platforms, it would relieve a bit of our maintenance work. But AFAIK there are performance and writing ability problems with that option, so it seems we could not replace our current ecw, mrsid, etc. providers. Just for curiosity, why is needed that approach in MacOSX? Is there any problems in the gvSIG JNI libraries? If that option is needed and you need your own branch, you could use the same gvsig-desktop repository. I think that way it will be easier for you to merge changes between the trunk and your branch, as you would be making changes on the same gvsig projects. For gvSIG 2.0, we will need more testing but I think we currently support that one format might be supported by many different providers, so the user is allowed to select which one to use. For example, in linux when the user opens an ecw file, he could select if he wants to open it through gdal or the current direct provider. For mac, if the direct one does not work, it would not be included in the installation. That way we could have both approaches in the main branch. Well, in that case not even in the gvsig-desktop svn repo, as from gvsig 2.0 onwards, the raster support has its own OSOR project and repository where you could work also. And the UI changes, I think the main problem is related to panels which use absolute positioning, instead of relative positioning using any of the available standard swing layouts. If those panels are updated, I think that would solve another problem we have when the Look & Feel is changed, as I think it is the same problem you might have in macOSX. If we were lucky and that would be the case, we could use the new Nimbus L&F, much more interesting IMHO. And if that is not the case, and branching is the only way to go, as I said you could use the gvsig-desktop project repository also, I think it will make life easier for you. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Eclipse RCP with gvSIG
Hi Tobias, First of all I advice you to decide which version of gvSIG to use. There are some important changes between the 1.x and 2.x branches, mainly at the data access level and other base libraries. The 1.x branch is the stable branch now, with the 1.11 version almost ready. I think this is the most interesting one if you were going to add some functionality and distribute it in addition to the one provided with the gvSIG application. The 2.x branch is now performing an initial stabilization process to prepare the final 2.0 version. Not all plugins available in 1.x are going to be available initially when it is ready, but most of them will. IMHO, this the more interesting one if you can wait a bit, won't need the funcionality of those plugins, or if you are going to work at the libraries level, as it seems is your case. Why? Because it is easier to use those libraries, some of them have a more delimited API, and more important, there is or will be more developer's documentation about them: http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel Part of it is already available in English, hope that will grow over time. Just for curiosity, could you tell us a bit about what are you going to develop with gvSIG? If you are allowed to do it, of course. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) El 08/04/11 11:53, Neumann, Tobias escribió: Dear José, thank you for this information. I have signed these three groups to pursue and understand the developments of gvSIG. It would be preferable if the spanish speaking developers would take more interest on the international developer mailing list. I have learned spanish three years at school, but I have to take a look on my schoolbooks again before I can enrich this community :-) Do you have any information about some sample code for using the features of gvSIG like adding data to layers and so on? I am feeling a little bit left alone at this part... Buen fin de semana :-) Tobias *From:* gvsig_internacional-boun...@listserv.gva.es on behalf of José Antonio Canalejo Alonso *Sent:* Thu 07.04.2011 21:47 *To:* Users and Developers mailing list *Subject:* Re: [Gvsig_english] Eclipse RCP with gvSIG Hello Tobias, I would like to say you where you can find more information to develop gvsig yourself: - English spoken developers mailing list (https://lists.forge.osor.eu/listinfo/gvsig-desktop-devel): it has low traffic because there are not many gvSIG English spoken developers but you should also read and write in this list. Developers for other projects work together there. - Spanish spoken developers mailing list (http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_desarrolladores): it has high traffic because there are many and highly qualified developers. If you can read/write spanish you will have very good information to develop gvsig. - Public mailing list of the gvSIG Technical Steering Committee -TSC (https://lists.forge.osor.eu/listinfo/gvsig-desktop-tsc-pub): This list is probably the most important one for people who need to know how gvsig is being developed. The allowed languages for the TSC list are Spanish and English. Most of the discussion is done in Spanish but don't hesitate to ask in English if you have cuestions. People there are open and they make a good documentation of their meetings that you can read if you can speak spanish. Nice to see you in the gvsig lists! Schönes Wochenende! José -- José Antonio Canalejo Alonso CSGIS Email:jose.canal...@csgis.de Web: http://www.csgis.de <http://www.csgis.de/> *De:* "Neumann, Tobias" *Para:* Users and Developers mailing list *Enviado:* jue,7 abril, 2011 13:35 *Asunto:* Re: [Gvsig_english] Eclipse RCP with gvSIG Dear Jordi, thank you for your suggestion. My job is just to build a working prototype in Eclipse RCP. Other people will rack their brains for license issues :-) I will tell them regarding these obscurities. With best regards Tobias -Ursprüngliche Nachricht- Von: gvsig_internacional-boun...@listserv.gva.es <mailto:gvsig_internacional-boun...@listserv.gva.es> im Auftrag von Jordi Torres Gesendet: Do 07.04.2011 13:22 An: Users and Developers mailing list Betreff: Re: [Gvsig_english] Eclipse RCP with gvSIG Hi Juan Lucas, I believe you are rigth, Tobias is able to distribute a plugin, that way he is not mixing GPL code with EPL code, is the final user who do that. My intention was only to advice Tobias to be careful with license incompatibilities. Cheers. 2011/4/7 Juan Lucas Domínguez Rubio <mailto:juan_lucas...@yahoo.com>> > Hello, > If I understood it well, it's not legally possible to distribute a "tuned" > version of Eclipse wher
Re: [Gvsig_english] Eclipse RCP with gvSIG
Hi Tobias, El 06/04/11 07:35, Neumann, Tobias escribió: Hello, I am interested in your experiences with the gvSIG software embedded in Eclipse RCP. I want to start up a project using these technologies. Anyone did this before? Are there some points I have to focus on? I don't know if someone has tried something like that before. Take into account that the gvSIG interface is based in java AWT and Swing libraries. I have no idea if you can mix easily Swing and eclipse RCP components, as they are very different technologies. If that is not possible or easy, you could use the gvSIG libraries and implement by yourself the map rendering components, but that would be a lot of work indeed. I think it would be far easier to personalize the gvSIG application to your needs, the gvSIG plugins mechanism allows to change a lot of gvSIG user interface settings without needing to touch the core gvSIG code. If even that is not an option, you could use the Netbeans RCP which is swing based and I suppose much easier to integrate with. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) Thank you very much! Best regards, Tobias Tobias Neumann, M.Sc. in Geogr. Softwareingenieur Tel: +49 89 608090-276 Fax: +49 89 6098182 E-Mail: tobias.neum...@berner-mattner.com Web: www.berner-mattner.com Berner & Mattner Systemtechnik GmbH Erwin-von-Kreibig-Str. 3 D-80807 München Geschäftsführer: Hans Berner, Dr. Klaus Eder, Dr. Jan-Oliver Wenzel Registernummer: HR B 83252 beim Amtsgericht München Sitz der Gesellschaft: München ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG 1.11 RC2 available
El 02/04/11 13:11, Antonio Falciano escribió: > Il 01/04/2011 17.23, Antonio Falciano ha scritto: >> Il 01/04/2011 14.59, gvSIG News Office ha scritto: >>> gvSIG has published a new distribution of the version 1.11 (gvSIG 1.11 >>> RC2). The second release candidate is product of the stabilization >>> process of this version. >>> >>> >>> As usual, it is available from the Download section of the website [1]. >>> >>> Check the known problems and improvements in this distribution from >>> the Version notes section [2]. >>> >>> In addition, coinciding with the publishing of the final version of >>> the 3D Extension, Rafael Gaitán, in collaboration with the University >>> Institute of Control Systems and Industrial Computing (ai2) of the >>> Universidad Politécnica de Valencia, has released a new non-official >>> gvSIG distribution for Mac, that includes the 3D Extension. This >>> version is available on the Other distributions section [3] of gvSIG >>> Desktop at the website. >>> >>> >>> [1] >>> http://www.gvsig.org/web/projects/gvsig-desktop/official/gvsig-1.11/downloads >>> [2] >>> http://www.gvsig.org/web/projects/gvsig-desktop/official/gvsig-1.11/notas-de-version >>> [3] http://www.gvsig.org/web/projects/gvsig-desktop/other-distributions >>> >> All downloads require the OSOR login, so they're not accessible. Please, >> check it. Many thanks. > Hi all, > the above mentioned problem still persists. Luckily, it's possible to > download gvSIG 1.11 RC2 directly from this page: > http://forge.osor.eu/frs/?group_id=89 > > Cheers, > Antonio Hi Antonio, In this RC2 we made some corrections to solve the bug in the sextante plugin you reported in the RC1. If you have the opportunity to test it again with this RC2, we will be glad if you could tell us how has been going. Thanks in advance, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] Feature request: progress bar when loading big layers
El 31/03/11 18:50, Antonio Falciano escribió: > >> The question about loading vectorfiles is interesting, I think. As >> I've got already problems with raster files @ 25MB...(start parameter >> at 256MB) >> >> I've tested some shapefiles (from http://downloads.cloudmade.com) >> with the gvSIG Mobile src running in Eclipse (OS: Windows 7): >> >> File: france_highways.shp (size = 336277700) >> Error: "Error while opening file: Not enough memory" => no layer >> in ToC, but it is loaded into the map view!?? >> >> File: spain_highways.shp (size = 185766396) >> Error: same error message >> >> File: germany_natural.shp (size = 152891836) >> Error: no problems! >> >> File: germany_highways.shp (size = 810905604) >> Error: not enough memory - of course >> >> >> The problems seem to start at about 150MB? Does it depend on the >> computer or does it depend on java itself? is there any differences >> using gvsig mobile or gvsig desktop (while loading shape files) ? > Your test is very interesting and useful for debugging, I think. The > bottleneck should depend by a combination of these factors, plus the > particular used driver. For instance, I was not able to load a DXF layer > of 60 MB on gvSIG Desktop 1.10 today. > > Cheers, > Antonio Yes, one of the main factors is the driver, some of them load everything into memory (ex: DXF), others read everything from disc (ex: SHP). I think it's very difficult to define a size limit for vectorial layer files, because there are a lot of factors involved: - Driver type. - Geometry complexity. - Available alphanumeric data. - If any operation has been performed in the layer: symbology, labeling, ordering, filtering, etc. ... At least, a better behavior when loading a layer which does not fit in memory could be developed, notifying about the error and not loading an empty layer. But its only a supposition, some investigation would need to be performed to see if it is feasible. About the progress bar, I agree also. At least a waiting cursor could be used. I think you could create two new feature requests about those two problems, so they don't get forgotten. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG 1.11 RC1 available
El 25/03/11 10:53, Wolfgang Qual escribió: > Dear Antonio, dear developers, > > it would be great, if additional tools could be added to gvSIG without the > necessity to install anything (scripts could be copied to the correct > location, maybe $home/gvSIG/scripts. I think that quite some extensions of > gvSIG are just unpacked by the installer. Compilation does not take place. > Or is it different? > We do not even have writing permission to the gvSIG installation > (/opt/gvSIG_1_10/...). Maybe there are similar conditions in other > administrations that use gvSIG. > > Best, > Wolfgang Hi Wolfgang, No, there is not any compilation performed in the installation process. We have been already thinking about a solution like the one you propose, to be able to install new plugins into a user home folder. But this needs some changes into the gvSIG internals, and it has also some subtle problems that may make it harder to be solved. Would you please add a feature request about the problem in the gvSIG OSOR tracker [1]? I don't think it will be solved for the 1.x version, unless there is any volunteer, but maybe we are able to tackle it for a post 2.0 version. [1] https://forge.osor.eu/tracker/?atid=790&group_id=89&func=browse Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG 1.11 RC1 available
El 24/03/11 16:58, Antonio Falciano escribió: > Il 24/03/2011 16.33, Cèsar Ordiñana ha scritto: >> El 24/03/11 10:47, Antonio Falciano escribió: >>> Hi Wolfgang, >>> the Add-ons installer seems to work fine! :-) I've successfully >>> installed the normalization and remote sensing extensions and they are >>> loaded correctly after restarting gvSIG. >>> On the other side, SEXTANTE (not tested by gvSIG team) is not working >>> fine as it did in gvSIG 1.10 and the "cachedir/packages dirs + field >>> calculator" problem (on Vista and 7) is not fixed yet. In the first >>> case, the workaround consists into deleting "es.unex.sextante" >>> directory >>> and replacing it with the one coming with gvSIG 1.10 (or with a newer >>> version). In the second, we need to start gvSIG as administrator and >>> launch the Jython console. >>> >>> Cheers, >>> Antonio >> Hi Antonio, >> >> We have made some changes in the sextante integration with gvSIG to >> allow working with bigger raster files and also some performance >> optimizations, but it seems there's something wrong with it. >> >> Could you give us more info about the errors do you have while using >> sextante? > > Hi Cèsar, > for instance, when I try to rasterize a vector layer, a > java.lang.ArrayIndexOutOfBoundsException occurs which doesn't allow to > execute the process successfully. Here's the sextante.log attached. > > Cheers, > Antonio Thanks Antonio, I'm going to add a new bug report about this. Have you tried by chance any of the raster only sextante tools? Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG 1.11 RC1 available
El 24/03/11 10:47, Antonio Falciano escribió: > Hi Wolfgang, > the Add-ons installer seems to work fine! :-) I've successfully > installed the normalization and remote sensing extensions and they are > loaded correctly after restarting gvSIG. > On the other side, SEXTANTE (not tested by gvSIG team) is not working > fine as it did in gvSIG 1.10 and the "cachedir/packages dirs + field > calculator" problem (on Vista and 7) is not fixed yet. In the first > case, the workaround consists into deleting "es.unex.sextante" directory > and replacing it with the one coming with gvSIG 1.10 (or with a newer > version). In the second, we need to start gvSIG as administrator and > launch the Jython console. > > Cheers, > Antonio Hi Antonio, We have made some changes in the sextante integration with gvSIG to allow working with bigger raster files and also some performance optimizations, but it seems there's something wrong with it. Could you give us more info about the errors do you have while using sextante? Thanks in advance, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvsig 1.9.x - 2.0 and jython
Hi Georg, El 04/02/11 12:22, georgsedlmeir escribió: > Jorge, > in case you should need another tester you could count me in, I am strongly > interested in the upcoming gvSIG scripting features. For the time being it > seems that there isn't an official gvSIG jython API available, at least my > search didn't actually yield results apart from the tutorial to be found on > the gvSIG website. > Do you know of further documentation describing the gvSIG scripting object > model in detail? Thank you very much. > > Best regards, > Georg Sedlmeir In the case of the new scripting plugin available in gvSIG 2.0, our initial plan is to provide access to all (or almost all) the gvSIG Java API from any script, as the supported scripting languages allow to call Java code (bytecodes actually) more or less easily. So to create a script you will be able to use the same documentation and examples available to develop gvSIG java plugins. In the plugin's current state you have access to the gvSIG 2.0 core Java API, and some work has still to be done so any gvSIG plugin is able to make its own API available to the scripts. That's our idea for the gvSIG 2.0 initial release. In the future we would like to use the scripting languages facilities to create a DSL [1] to make gvSIG scripting easier, but can't tell for sure and for which scripting languages. It will depend on available resources and if there are any volunteers. Just in case anyone is interested, the scripting languages available in the scripting plugin are: - Python (Jython) - Ruby (JRuby) - Groovy - Javascript/ECMAScript We planned initially to include Beanshell support also, but if you want to use the Java syntax, you can do it through Groovy. [1] http://en.wikipedia.org/wiki/Domain-specific_language Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] wps bakeoff - any interest?
Hi Jody, El 01/02/11 10:42, Jody Garnett escribió: > Morning team: > > After last years foss4g there was some interest in doing a bit of a "wps > bakeoff". Now most of that interest was coming from the various server > implementations (52n, deegreee, geoserver, pywps, zoowps) - who probably want > a chance to compare performance numbers. > > I would like to see the various client applications take part; in particular > to ensure that the servers can be driven by a deskop client like gvSig > without prior knowledge (ie just from the describe process document). > > This week I am contact the development teams, and I would like to ask you to > consider: > - what would you like to see out of a "wps bakeoff"? > - check (perhaps at your next meeting) if there is time to take part. > > Cheers, > Jody Thanks for the contact and the information about the "wps bakeoff". We will talk about it and see what we are able to do. Also maybe someone in the gvSIG community wants to perform the bakeoff. In any case, could you give as some more information about the initiative? Is it being backed up by any organisation? There is any plan, timing, resources, etc. already available? Thanks in advance, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG metadata extension
Hi Georg, El 26/01/11 14:34, georgsedlmeir escribió: > Dear gvSIG community, > can anybody provide me with status information about the gvSIG metadata > extension? Apparently the prototype once was part of the 1.1.x release but > this doesn't seem to apply for more recent versions. > Are there any plans to integrate it into v2.0, and has there been further > development going on since the > prototype was published? What would be the current status? Thank you very > much. > > Best regards, > Georg Sedlmeir The metadata extension prototype had been discontinued and is not available for newer 1.x versions. For the v2.0, there is an ongoing development project of the Universitat Jaume I de Castelló to add metadata support. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
[Gvsig_english] gvSIG 2.0: Changed the org.gvsig.symbology project location into the subversion repository
Hi, The location of the org.gvsig.symbology project has been moved into the subversion repository from: https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/extensions/org.gvsig.symbology To: https://svn.forge.osor.eu/svn/gvsig-desktop/branches/v2_0_0_prep/libraries/org.gvsig.symbology Moreover, the project has been transformed to a maven multimodule project. For anyone who is going to prepare a new gvSIG 2.0 workspace, that change won't be noticed. But, the ones who had already prepared it will have to delete the old project in their filesystem and checkout the new one from subversion, or they will get an error performing an update from subversion. Sorry for the inconveniencies. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvsig svn trunk and 2.0 position?
Hi Giovanni, In trunk you will find what will become the next stable version (1.10.0). The 1.9.0 stable version can be found in tags/v1_9_Build_1253. The 2.0.0 version is being developed in branches/v2_0_0_prep. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) G. Allegri escribió: > Dear Gvsig developers, > I'm not sure about the gvsig svn organization. I see there are a lot > of branches and tags, but I'm not sure (seeing the commit activity) > about the position of the 2.0 (development) and the 1.9 maintained > versions. > I suppose that the lates 1.9 is in trunk, and 2.0 in some > tags/branches. Could you sum me up the state of the svn structure? > > Thanks a lot, > Giovann ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG 2.0 compilation instructions synthesis for English speaking readers
Hi Luca, I have read your steps. I'm sorry but I think you got a bit confused in the process, as your explanation has some wrong or unnecessary steps. Just in case, the steps to perform are explained in the document: http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/trabajar-con-el-nucleo-de-gvsig/gvsig-compilation/initial-configuration/howto-create-eclipse-workspace I think it is important not to summarize it as anyone following the steps should perform all of them and understand them as some decisions have to be made. It is a process a developer will not perform many times, less so when we finally generate a build. Unfortunately, the document is still only in Spanish. Looking towards having the compilation document in English, I invite everyone to collaborate on the translation of gvsig.org, as explained in the page: http://www.gvsig.org/web/home/community/participate In any case, we will try to translate the gvSIG developer's guide ASAP. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) luca bianconi escribió: Hi all, just a quick news, useful for English speaking gvSIG beginners: I've posted on my blog [1] a synthesis of the necessary steps to download and compile the last version of our beloved application, as I've discovered and understood them in this month just gone by. It includes the setting of the dependencies, the environment and of Eclipse. I'm still reviewing it so if someone likes giving it a glance and maybe suggesting integration and fixing I'd be very happy of adding your informations to the post. It's available at this address: http://www.iosa.it/content/compiling-gvsig-20-ubuntu-1004-lts-910-1st-part Thanks for your help, Cheers, Luca [1] http://www.iosa.it/blogs/luca ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] The archive: /build/product/lib/castor-0.9.5.3.jar which is referenced by the classpath, does not exist.
Hi Luca, luca bianconi escribió: Hi all, I've compiled gvSIG 2.0.0 as in documentation [1] but with an error I could avoid compiling without tests. It's been compiled alright (wihtout tests) but when I boot the application I get this message "The archive: /build/product/lib/castor-0.9.5.3.jar which is referenced by the classpath, does not exist." and the application doesn't boot. Jar files in the folder /build/product/lib/ are generated by maven. Sometimes eclipse doesn't realise about changes in that folder and as those jars are referenced by the gvSIG eclipse launcher it shows that error. Look at that folder through a file explorer to confirm that the castor-0.9.5.3.jar file is already there. Next, go to eclipse and refresh that folder through the package explorer, project explorer or the navigator. Finally, try again to run gvSIG through the launcher. I will add this error to the documentation just in case someone else gets hit by it again. One solution to this would be if eclipse would allow us to define the launcher classpath by taking all jar files from a folder, instead of each jar file individually. Any ideas anyone? I've compiled and boot alright the day before yesterday the 2.0.0 gvSIG build from the branches/prep_2_0_0/build from the svn repository, as described in documentaiton [1]. I got an error when creating a plugin with the plugin creation wizard from the menu bar. At the end of the process of creation gvSIG I get a "USER ERROR" with a long error message. Let me check that plugin to see if it is working. As we are making some last changes to prepare a developer's build, there are some thinks that need to be checked again. I've decided to recompile gvSIG and that's what I've got. Anyone could help me ? Cheers, Luca Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] New Student for GVSIG within Google Summer OfCode2010: quick introduction
Hi Ben, Yes, I think so. The simple model will let Luca learn about gvSIG development and have something to be able to play with in less time. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) Benjamin Ducke escribió: > Cesar, > > excellent point. SpatiaLite's indexing is maybe it's most important > advantage for our use. > > But I think we all agree that it would make sense for Luca to first > do the simple WKB/WKT storage model and then start working on the > SpatiaLite support? Depending on time, as you say, he may or may not > be able to finish it within this year's GSoC. > > Cheers, > > Ben > > - Original Message - > From: "Cèsar Ordiñana" > To: "Users and Developers mailing list" > Sent: Monday, May 17, 2010 1:51:56 PM GMT +01:00 Amsterdam / Berlin / Bern / > Rome / Stockholm / Vienna > Subject: Re: [Gvsig_english] New Student for GVSIG within Google Summer > OfCode2010: quick introduction > > > Hi Ben, > > Benjamin Ducke escribió: > > Hi Juan Lucas > > As for Luca's project, I think JNI (on top of OGR or > SQLite/Spatialite) is unavoidable, no? OpenJUMP's plugin might be a > reference, as somebody said. They are using a JAR that includes a > native library (.dll, .so) in it: > https://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=OpenJUMP_with_SpatialLite > Thanks for the link. There will certainly be interesting information > in there. > > If we go for the simple WKB/WKT storage model, then Luca could model > his work on the existing code for the PostGIS driver and avoid having > to use JNI, at least until support for the native SpatiaLite format > is required (but then that can still be done via the existing > GDAL/OGR driver bindings). > I agree the simple model may be interesting, as a way to be able to work with > existing sqlite databases or even as a first phase of development. > > That work should be quite quick and easy, as there is a base implementation > for JDBC based DAL providers, and our current Postgis and Mysql providers are > already reading and writing geometries in WKB format by themselves, so they > are good examples to start from. > > But I think we shall go to the full spatialite support. gvSIG needs support > for a local personal database, for many uses (cache, temporal storage, etc.), > and we still haven't one because the java based ones (HSQLDB, etc.) doesn't > have proper spatial support. With spatial support I mean, above all, spatial > indexes support, or I fear performance will suffer badly. > > I don't know if that work is too much to be done in the period available for > Luca in the GsC, and should be continued in the next year's GsC, or by some > other volunteer/s, but I would like to stress the importance of having > spatialite support, at least at spatial indexes level. > > Regards, > ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] New Student for GVSIG within Google Summer OfCode2010: quick introduction
Hi Ben, Benjamin Ducke escribió: Hi Juan Lucas As for Luca's project, I think JNI (on top of OGR or SQLite/Spatialite) is unavoidable, no? OpenJUMP's plugin might be a reference, as somebody said. They are using a JAR that includes a native library (.dll, .so) in it: https://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=OpenJUMP_with_SpatialLite Thanks for the link. There will certainly be interesting information in there. If we go for the simple WKB/WKT storage model, then Luca could model his work on the existing code for the PostGIS driver and avoid having to use JNI, at least until support for the native SpatiaLite format is required (but then that can still be done via the existing GDAL/OGR driver bindings). I agree the simple model may be interesting, as a way to be able to work with existing sqlite databases or even as a first phase of development. That work should be quite quick and easy, as there is a base implementation for JDBC based DAL providers, and our current Postgis and Mysql providers are already reading and writing geometries in WKB format by themselves, so they are good examples to start from. But I think we shall go to the full spatialite support. gvSIG needs support for a local personal database, for many uses (cache, temporal storage, etc.), and we still haven't one because the java based ones (HSQLDB, etc.) doesn't have proper spatial support. With spatial support I mean, above all, spatial indexes support, or I fear performance will suffer badly. I don't know if that work is too much to be done in the period available for Luca in the GsC, and should be continued in the next year's GsC, or by some other volunteer/s, but I would like to stress the importance of having spatialite support, at least at spatial indexes level. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) Cheers, Ben Nacho's work sounds very interesting too. Regards, Juan Lucas Domínguez Rubio --- Prodevelop SL, Valencia (España) Tlf.: 96.351.06.12 -- Fax: 96.351.09.68 http://www.prodevelop.es --- De: gvsig_internacional-boun...@listserv.gva.es en nombre de Benjamin Ducke Enviado el: lun 17/05/2010 9:28 Para: Users and Developers mailing list Asunto: Re: [Gvsig_english] New Student for GVSIG within Google Summer OfCode2010: quick introduction Ben, you know for sure much better than me what would mean having problems with wrapping of C API so if we will have too much pain with SpatiaLite it could be perfect use the plain WKT/WKB. I've given a glance to the link you've suggested but I should read it better for understanding what it means on the development point of view. Ciao, Luca I think for a first stage implementation, the simple WKB/WKT storage model is probably best. Others can always be added later using the new GDAL 1.7 java bindings. That way, you shouldn't have to worry about maintaining your own JNI stuff (which can be a real pain). Give users the choice to use WKB (more compact) or WKT (more easy to parse) when storing geometries. When reading, the format should be auto-detected. Let me know if you have any problems understanding anything. I can send you a little sample SQLite3 database with some WKB/WKT tables for illustration. I produced them in GRASS GIS using the GDAL/OGR drivers. But maybe start by adding plain SQLite3 non-spatial tables as a new project document type first. And then work towards spatial tables from there -- to keep things a little more simple for you at the start! Best, Ben [1] http://www.iosa.it/blogs/luca 2010/5/14 Benjamin Ducke Hi Juan, Luca That question is not so rhetorical, actually! There are several ways of storing spatial data in an SQLite3 database, that are all in use by some software: http://www.gdal.org/ogr/drv_sqlite.html One of them is a simple WKT/WKB storage model that is also nicely documented (see link above). So if SpatiaLite is too much pain, because of the need to wrap the C API, then we can just use the plain WKT/WKB storage for our purposes. It's supported by GDAL/OGR, so we lose only the special SpatiaLite functionality. Cheers, Ben - Original Message - From: "Juan Lucas Dominguez Rubio" To: "Users and Developers mailing list" , "Gvsig internacional" Sent: Friday, May 14, 2010 2:38:44 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [Gvsig_english] New Student for GVSIG within Google Summer Of Code2010: quick introduction Ciao, Luca. I too think Spatialite is a very interesting way to store and share GIS data, especially because its simplicity fits mobile devices very well. I know a pure-Java version of SQLite (not Spatialite) which will probably work on a wide range of Java-enabled mobile devices (Android supports SQlite
Re: [Gvsig_english] svn.checkout.all - BUILD ERROR - Failed toresolve artifact
Hi Luca, Sorry, we added by error a new project, still in development, to the build process. We will disable it until it is ready to be included again. Please, try now again. Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) luca bianconi escribió: > Hi all, > > thanks for the suggestion about JNI and .gvsig.platform.properties > native_distribution property modification, Cesar, you were right of > course! > > I've compiled JNI, etc. Everything's alright. > > I've got back to the point 11 of the document[1] related to the > initial configuration of a gvsig eclipse workspace but after having > selected the svn.checkout.all target I've got a new error a little bit > further during the compilation process: > > > [artifact:mvn] [INFO] > > [artifact:mvn] [INFO] Building org.gvsig.installer.lib.impl > [artifact:mvn] [INFO]task-segment: [install] > [artifact:mvn] [INFO] > > [artifact:mvn] Downloading: > http://gvsig-desktop.forge.osor.eu/downloads/pub/projects/gvSIG-desktop/maven-repository/org/gvsig/org.gvsig.tools.lib/2.1.0-SNAPSHOT/org.gvsig.tools.lib-2.1.0-SNAPSHOT-tests.jar > [artifact:mvn] [INFO] Unable to find resource > 'org.gvsig:org.gvsig.tools.lib:jar:tests:2.1.0-SNAPSHOT' in repository > gvsig-public-http-repository > (http://gvsig-desktop.forge.osor.eu/downloads/pub/projects/gvSIG-desktop/maven-repository) > [artifact:mvn] [INFO] > > [artifact:mvn] [ERROR] BUILD ERROR > [artifact:mvn] [INFO] > > [artifact:mvn] [INFO] Failed to resolve artifact. > [artifact:mvn] Missing: > [artifact:mvn] -- > [artifact:mvn] 1) org.gvsig:org.gvsig.tools.lib:jar:tests:2.1.0-SNAPSHOT > [artifact:mvn] Try downloading the file manually from the project > website. > [artifact:mvn] Then, install it using the command: > [artifact:mvn] mvn install:install-file -DgroupId=org.gvsig > -DartifactId=org.gvsig.tools.lib -Dversion=2.1.0-SNAPSHOT > -Dclassifier=tests -Dpackaging=jar -Dfile=/path/to/file > [artifact:mvn] Alternatively, if you host your own repository you > can deploy the file there: > [artifact:mvn] mvn deploy:deploy-file -DgroupId=org.gvsig > -DartifactId=org.gvsig.tools.lib -Dversion=2.1.0-SNAPSHOT > -Dclassifier=tests -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] > -DrepositoryId=[id] > [artifact:mvn] Path to dependency: > [artifact:mvn] 1) > org.gvsig:org.gvsig.installer.lib.impl:jar:1.0.0-SNAPSHOT > [artifact:mvn] 2) > org.gvsig:org.gvsig.tools.lib:jar:tests:2.1.0-SNAPSHOT > [artifact:mvn] -- > [artifact:mvn] 1 required artifact is missing. > [artifact:mvn] for artifact: > [artifact:mvn] org.gvsig:org.gvsig.installer.lib.impl:jar:1.0.0-SNAPSHOT > [artifact:mvn] from the specified remote repositories: > [artifact:mvn] central (http://repo1.maven.org/maven2), > [artifact:mvn] osgeo (http://download.osgeo.org/webdav/geotools), > [artifact:mvn] gvsig-public-http-repository > (http://gvsig-desktop.forge.osor.eu/downloads/pub/projects/gvSIG-desktop/maven-repository) > > > I guess it suggests I have not the > org.gvsig.tools.lib-2.1.0-SNAPSHOT.jar into my ./m2/repository folder, > but I have it there and I've also tried to compile and install it again. > > Have you another good suggestion for me by chance ? > > Thanks anyway, > Cheers, > Luca ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] svn.checkout.all - BUILD ERROR - Failed to resolve artifact
Hi Luca, luca bianconi escribió: Hi all, maybe someone can help me. I'm working with Ubuntu 10.04 and the latest gvsig v2_0_0_prep . I've got an error I couldn't fix when I've reached the point 11 of the document[1] related to the initial configuration of a gvsig eclipse workspace. The "BUILD FAILED" cause seems suggested by the error log: ... [artifact:mvn] Missing: [artifact:mvn] -- [artifact:mvn] 1) org.gvsig:org.gvsig.jgdal:tar.gz:linux-Ubuntu-10.04-gcc4-i386-dynamic:2.0.1-SNAPSHOT That error si caused because it is trying to find the jgdal JNI library compiled for Ubuntu-10.04 and it is not available so far. Just in case you did'nt know, gvSIG uses some native libraries through the JNI API, which have to be compiled for each platform. Currently we only have compiled binaries for the platforms stated in the following page: http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/trabajar-con-el-nucleo-de-gvsig/gvsig-compilation/initial-configuration/initial-configuration#configuraci-n-de-la-plataforma The last ubuntu version with available binaries is the 9.10 version (32 bits). We will have to compile them for Ubuntu-10.04 sooner than later, but in the meantime you can try to use the Ubuntu-9.10 ones by modifying your .gvsig.platform.properties files and setting the native_distribution property to Ubuntu-9.10. Also, you have to install the libgdal library in your Ubuntu, as we no longer distribute it with gvSIG for linux. It think that will probably work, unless the libgdal library version had been upgraded in Ubuntu 10.04. For Ubuntu 9.10 we link against libgal1-1.5.0. If you have a 1.6.0 version or higher, you will be able to compile and run gvSIG, but won't be able to open raster layers. In case anyone wants to try to compile the native libraries for another platform not already available, here you can find how to do it (sorry, only in Spanish so far): http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/trabajar-con-el-nucleo-de-gvsig/gvsig-compilation/jni-compilation Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] [INFO] Unable to find resource 'org.gvsig:gvsig-base-pom:pom: 2.0-SNAPSHOT
Hi Luca, To checkout and compile what we call the gvSIG core projects you must perform first the steps of the page "Cómo montar un workspace de gvSIG para Eclipse" (How to create a gvSIG workspace for Eclipse) [1] Once you finish those steps, you will be able to compile and run gvSIG as explained in the document you where following before. In any case, don't hesitate to ask for help if you find any problem following the steps of the page [1]. Also, next week we are going to try to create a developer's gvSIG 2.0 build, so anyone who wants to develop for gvSIG 2.0 doesn't need to compile the gvSIG core by himself. We'll also update the gvSIG 2.0 developer's guide to explain better how to work with this scenario. [1] http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/trabajar-con-el-nucleo-de-gvsig/gvsig-compilation/initial-configuration/howto-create-eclipse-workspace Regards, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) luca bianconi escribió: Hi all, just a quick question during first tests for compiling a gvsig-standard 2.0 project. I've got this message when tried to compile ( run mvn-install as in http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/trabajar-con-el-nucleo-de-gvsig/gvsig-compilation/how-to-compile-gvsig ): [artifact:mvn] Downloading: http://gvsig-desktop.forge.osor.eu/downloads/pub/projects/gvSIG-desktop/maven-repository/org/gvsig/gvsig-base-pom/2.0-SNAPSHOT/gvsig-base-pom-2.0-SNAPSHOT.pom [artifact:mvn] [INFO] Unable to find resource 'org.gvsig:gvsig-base-pom:pom: 2.0-SNAPSHOT' in repository gvsig-public-http-repository (http://gvsig-desktop.forge.osor.eu/downloads/pub/projects/gvSIG-desktop/maven-repository) [artifact:mvn] [INFO] [artifact:mvn] [ERROR] FATAL ERROR I guess I should change in some way (probably setting it somewhere) " -SNAPSHOT " with ".1". I suppose it's quite a beginners' problem as far as I've found some interesting links but I couldn't understand how to fix it: http://osgeo-org.1803224.n2.nabble.com/Instalador-de-extension-td4890755.html Thanks for any help, Luca ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] SUGGESTED FUNCTIONALITY gvSIG 1.9 (BN 1253) -- (repeat) need for default directory, project directory and temp directory
Hi Benjamin, About the file selector article, as the author explains, you lose some flexibility and customization options by using the awt file dialog instead of the swing one. I think it's a matter of usability which must be solved at the application level, making sure all gvSIG file dialogs have the same behavior and adding more functionality like the Simon's suggestions, file previewing, etc. Cheers, -- Cèsar Ordiñana Navarro gvSIG software architect DiSiD Technologies (http://www.disid.com) Benjamin Ducke escribió: > Hi Simon, > > have you noticed the settings under "File->Preferences-> > General->Default directories"? The "Spatial data directory" > defines the default path for layer files. It should be > respected by most file selectors in gvSIG. > > A good thing to be considered in a future version of gvSIG > may be to provide an option to use the system's native > file selectors instead of Java's Swing ones. > The necessary modifications would be really simple and are > described here: > > http://today.java.net/pub/a/today/2004/01/29/swing.html > > All modern desktops now have file selectors that allow > you to set system-wide "bookmarks" for folders, so that > would solve the problem on a higher level. > > Of course, there is another option to avoid the problems > with file-based data management altogether: use a spatial > database such as PostGIS. If we get the SpatiaLite GSoc > project this summer, than that will give you a perfectly > simple option to store spatial data neatly in one location. > > Cheers, > > Ben > > > > - Original Message - > From: "Simon Cropper" > To: "Users and Developers mailing list" > Sent: Monday, April 12, 2010 8:23:25 AM GMT +01:00 Amsterdam / Berlin / Bern > / Rome / Stockholm / Vienna > Subject: [Gvsig_english] SUGGESTED FUNCTIONALITY gvSIG 1.9 (BN 1253) -- > (repeat) need for default directory, project directory and temp directory > > > Hi, > > I know I have posted this before but I and currently doing some basic work > and have resulted in multiple copies files ending up everywhere and thought I > would stress the point. > > As an example, I am attempting to create a polygon file from a CAD drawing > showing mutually exclusive development zones. Basic vector data has been > polygonised, cleaned, exported, split and remerged. I also used buffers to > obtain exact distances from boundaries and used Sextante many times in the > process. > > So... CAD --> intermediate files --> Polygon layer showing various mutually > exclusive development zones. > > This resulted in... > > Actual project map directory where I attempted to push output but gave up due > to continuous drilling down of the directory tree in dialog boxes and > plug-ins, even when you choose the 'source' and 'destination' in the same > dialog box ==> 14 shapefiles, 1 DXF file (original DWG) > > My 'Home' Directory (default location for some routines) ==> 11 shapefiles > > A temporary TEMP directory I created in my Home Directory because I was sick > of the clutter ==> 4 shapefiles > > The default gvSIG/bin Directory (default location for some other routines) > ==> 7 files > > Now this is just one aspect of my analysis yet it created 36+ files in > multiple directories and requires time to clean up. > > gvSIG absolutely needs a PROJECT DIRECTORY and a TEMP DIRECTORY that all > routines and plug-ins use as a default. At least in the short term, > considering this would take time to implement, icons should be placed on the > directory tree dialog that allows you to move to these directories quickly. > -- > > > Cheers Simon > > Simon Cropper > Botanicus Australia Pty Ltd > PO Box 160, Sunshine, Victoria 3020. > P: 9311 5822. M: 041 830 3437. > mailto: scrop...@botanicusaustralia.com.au > web: www.botanicusaustralia.com.au > ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] [GSoC] Mentoring a gvSIG GSoC idea
Hi Fran and Ben, If you need some help with the Data Access Layer in gvSIG 2.0, I can offer myself too. If there exists a working JDBC driver for sqlite/spatialite, it should not take too much effort to develop the new provider. In gvSIG 2.0 there is a generic JDBC provider, which is extended by the postgreSQL/Postgis provider (and the other jdbc based providers) which can be used as a base to develop the sqlite/spatialite provider. I have found a JDBC driver project for sqlite (http://www.zentus.com/sqlitejdbc/), but don't know if it works with spatialite. But if the JDBC option is not available, we should revert to JNI, in which case the project will require a lot more effort, may be too much for the 3 months period. Regards, Francisco José Peñarrubia escribió: Hi Ben and Jukka. I don't know much about Data Access Layer in gvSIG 2.0, but I think for this summer I will or at least, I can ask other people here about it ;-). I can offer myself to co-mentor this project. Best regards. Fran Peñarrubia www.scolab.es Rahkonen Jukka escribió: Hi, There is something about Spatialite and OpenJUMP at http://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=OpenJUM P_with_SpatialLite It might be worth having a look. -Jukka Rahkonen- Benjamin Ducke wrote: Yes, it would be good if someone could co-mentor this with me. I know SQLite3 quite well, but do not have any experience with the gvSIG 2.0 data access layer yet. Cheers - Original Message - From: "Miguel Montesinos" To: "Users and Developers mailing list" Sent: Monday, April 5, 2010 8:47:08 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: [Gvsig_english] [GSoC] Mentoring a gvSIG GSoC idea Hi, Some tests have been done in the past with H2, but SQLite3 would be great. We have to coordinate GSoC proposals ASAP. Cheers, Miguel Montesinos -Mensaje original- De: gvsig_internacional-boun...@listserv.gva.es en nombre de silvio grosso Enviado el: vie 02/04/2010 9:23 Para: Users and Developers mailing list Asunto: Re: [Gvsig_english] [GSoC] Mentoring a gvSIG GSoC idea Hi Ben, Benjamin Ducke wrote: I'd like to mentor a student (and I probably have a candidate,already) to implement support for SQlite3 tables (both simple tables and spatial tables) in gvSIG. WOW!!! I am sure SpatiaLite support would be really a Must for gvSIG 2. Not to mention that other Open Source GIS already support it ;-) Best regards, Silvio ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] gvSIG 1.9 patch for managing measured 3D Polylines of Shapefiles
Hi Alberto, Sorry, I missed your message until today. There is a guide for gvSIG 2.0 developers [1] where you can find a section about migrating a project to gvSIG 2.0 [2]. As of now, that documentation is only available in spanish, but soon it will be translated to english. In the meantime, I hope you can use the google translation tools to be able to read it. In any case, don't hesitate to ask any questions you may have about the migration process. [1]: http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide [2]: http://www.gvsig.org/web/projects/gvsig-desktop/docs/devel/gvsig-devel-guide/2.0.0/howto-migrate-projects-to-gvsig-2-0 Regards, -- Cèsar Ordiñana Navarro Arquitecto Software gvSIG DiSiD Technologies SL http://www.disid.com Francisco José Peñarrubia escribió: Hi Alberto. About porting, it depends on the extension, of course, but the answer is YES, with a bit of work. I haven't seen the code, but I suppose you will need to change things like exceptions, and the geometry model is different in 2.0, so migrating one extension from 1.9 to 2.0 is more work than from 1.1.2 to 1.9, for example. Also, FeatureIterators are changed, and the whole model of accesing data, among other things. In the other hand, windows and user interface may suffer little changes. Anyway, there are people in this list than can answer better than me about that. Maybe they can correct me if I am wrong. About documentation, this is the only docs I know by now: http://www.gvsig.org/web/docdev/gvsig_desktop_2_0/ but I'm pretty sure you already know. Best regards, and good luck!!!. Fran. Alberto Perli escribió: Hi Francisco, we have seen in Valencia, talking about the italian project on extending gvSig with Z&M coordinates. Flavio's patch is developed in this project, so, talking with our team but in particular with customers, there is the hope to see the patch in 1.9.1 release, but in 2.0 too! In fact we are working on a new extension on 1.9 release (the extension will be ready at the end of April), and the big question is: The extension we are developing on 1.9, could be ported in 2.0? If not, there will be some specification or guidelines to easily migrate the extension from 1.9 to 2.0 model? Thanks, Alberto ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] (no subject)
Hi Holger, As Fran has already pointed at, gvSIG 2.0 will provide a new implementation for the data access layer (dal), which avoids the need for random position access, so in the case of a database, data is only loaded when requested. Hopefully, gvSIG 2.0 will have less memory problems depending on the size of a database table, but we still have to perform more testing to stress those cases. Regards, -- Cèsar Ordiñana Navarro Arquitecto Software gvSIG DiSiD Technologies SL http://www.disid.com Francisco José Peñarrubia escribió: Hi Holger. I think this behaviour is different in gvSIG 2.0. The reason is in 2.0 release, the random access is not needed like in 1.9 release. So, you only have 2 options, wait for 2.0 release, or use a where clause in the layer creation. I think you can define your "working area" from the dialog of postgis layer loading (in 1.9). Best regards. Fran. Holger Jaekel escribió: Dear gvSIG developers, when we add a layer from PostGIS to gvSIG 1.9, we can see that two ressource intensive operations are performed on the database: 1. A database cursor is created for this layer in PostGisDriver.setData(IConnection, DBLayerDefinition), which selects all objects from the table 2. A Hashtable is filled in PostGisDriver.doRelateID_FID(), which contains one entry for each object from our layer. We have to work with layers that contain more than 10,000,000 polygons. In that case, the cursor allocates many ressources on the database side, so this solution does not scale very well for many users. In the second step, gvSIG tries to create a Hashtable with >10,000,000 entries, which will create an OutOfMemoryException. This will also happen if we use "maxScale" for this layer. Any hints how gvSIG can handle large layers? Thank you very much for your help, Holger ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] FEEDBACK gvSIG 1.9 (BN 1253) -- use of gvSIG in production environment
Hi Ben, I agree with you, a database is the way to go for that scenario. Just in case someone faces up with that problem, and wants to develop the file level locking support, I think it would be more feasible now, so don't hesitate to ask for guidelines. Regards, Benjamin Ducke escribió: > Hi Cesar, > > that sounds excellent. Regarding file level locking, > I think you should not bother with it too much. > If people need multi-user access to geodata, they > should use a PostGIS databases and leave it to the > DBMS to handle conflicts -- it's designed to do that. > File system locking will never work that well. > > Cheers, > > Ben > > - Original Message - > From: "Cèsar Ordiñana" > To: "Users and Developers mailing list" > Sent: Wednesday, January 20, 2010 2:22:16 PM GMT +01:00 Amsterdam / Berlin / > Bern / Rome / Stockholm / Vienna > Subject: Re: [Gvsig_english] FEEDBACK gvSIG 1.9 (BN 1253) -- use of gvSIG in > production environment > > Hi Simon, > > First of all, thanks for all your feedback, suggestions and errors > reported. > > I'm deeply involved in the development of the gvSIG 2.0, so I would like > to explain what is being done in relation to your points 6 and 8. > > One of the main changes in gvSIG 2.0 is a complete design and > implementation of the data access library. Knowing the problems of > previous versions, like the ones you have highlighted, we added resource > management to the library implementation. > > This way, if the user opens many layers in the same or different views > from the same file, or even many table documents, we know they share the > same file. The resource management service also locks write access to a > resource, so two different layers (in the same gvSIG instance) can't > write a file at the same time, but one after the other. > > So now we have the basic tools to be able to solve some of those > problems, but still have to do some work to translate that knowledge to > the application level. Things like: > > - If you finish editing a layer, refresh other layers from the same file. > - Warn the user that he's trying to edit a layer which is being edited > in another view. > - ... > > I'm not sure how much development effort we will be able to spend in > this problem, but I think in gvSIG 2.0 we will be able to handle those > cases more gracefully, at least for the most regular ones. > > All of this for the single gvSIG instance with many layers/views of the > same file scenario. For the scenario of many gvSIG instances or other > applications opening the same file, we could use file locking at the > system level. But I hope this to be a more unusual case, as I don't > think we will be able to work on it for the gvSIG 2.0 release. > > Regards, > > ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] FEEDBACK gvSIG 1.9 (BN 1253) -- use of gvSIG in production environment
Hi Simon, I think it will take something between 4 - 6 months. It's a bit hard to give a more definite estimation, as we need to coordinate with a lot of people and organizations involved in the project. In any case, we expect to update the roadmap soon, so we could give a more detailed estimate. Regards, -- César Ordiñana Navarro gvSIG software architect DiSiD Technologies SL http://www.disid.com Simon Cropper (Botanicus Australia Pty Ltd) escribió: Cèsar, Thanks for the information. It is very good that you are addressing this issue and I look forward to the release of Version 2. I recently looked at the published road map for the project but this is out of date. Can you estimate when the next version will be released - 1, 6, 12 months? Cheers Simon Simon Cropper Botanicus Australia Pty Ltd PO Box 160, Sunshine, Victoria 3020. P: 9311 5822. M: 041 830 3437. mailto: scrop...@botanicusaustralia.com.au <mailto:scrop...@botanicusaustralia.com.au> web: www.botanicusaustralia.com.au <http://www.botanicusaustralia.com.au> On 21/01/2010 12:22 AM, Cèsar Ordiñana wrote: Hi Simon, First of all, thanks for all your feedback, suggestions and errors reported. I'm deeply involved in the development of the gvSIG 2.0, so I would like to explain what is being done in relation to your points 6 and 8. One of the main changes in gvSIG 2.0 is a complete design and implementation of the data access library. Knowing the problems of previous versions, like the ones you have highlighted, we added resource management to the library implementation. This way, if the user opens many layers in the same or different views from the same file, or even many table documents, we know they share the same file. The resource management service also locks write access to a resource, so two different layers (in the same gvSIG instance) can't write a file at the same time, but one after the other. So now we have the basic tools to be able to solve some of those problems, but still have to do some work to translate that knowledge to the application level. Things like: - If you finish editing a layer, refresh other layers from the same file. - Warn the user that he's trying to edit a layer which is being edited in another view. - ... I'm not sure how much development effort we will be able to spend in this problem, but I think in gvSIG 2.0 we will be able to handle those cases more gracefully, at least for the most regular ones. All of this for the single gvSIG instance with many layers/views of the same file scenario. For the scenario of many gvSIG instances or other applications opening the same file, we could use file locking at the system level. But I hope this to be a more unusual case, as I don't think we will be able to work on it for the gvSIG 2.0 release. Regards, ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional ___ Gvsig_internacional mailing list Gvsig_internacional@listserv.gva.es http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
Re: [Gvsig_english] FEEDBACK gvSIG 1.9 (BN 1253) -- use of gvSIG in production environment
Hi Simon, First of all, thanks for all your feedback, suggestions and errors reported. I'm deeply involved in the development of the gvSIG 2.0, so I would like to explain what is being done in relation to your points 6 and 8. One of the main changes in gvSIG 2.0 is a complete design and implementation of the data access library. Knowing the problems of previous versions, like the ones you have highlighted, we added resource management to the library implementation. This way, if the user opens many layers in the same or different views from the same file, or even many table documents, we know they share the same file. The resource management service also locks write access to a resource, so two different layers (in the same gvSIG instance) can't write a file at the same time, but one after the other. So now we have the basic tools to be able to solve some of those problems, but still have to do some work to translate that knowledge to the application level. Things like: - If you finish editing a layer, refresh other layers from the same file. - Warn the user that he's trying to edit a layer which is being edited in another view. - ... I'm not sure how much development effort we will be able to spend in this problem, but I think in gvSIG 2.0 we will be able to handle those cases more gracefully, at least for the most regular ones. All of this for the single gvSIG instance with many layers/views of the same file scenario. For the scenario of many gvSIG instances or other applications opening the same file, we could use file locking at the system level. But I hope this to be a more unusual case, as I don't think we will be able to work on it for the gvSIG 2.0 release. Regards, -- César Ordiñana Navarro gvSIG software architect DiSiD Technologies SL http://www.disid.com Simon Cropper (Botanicus Australia Pty Ltd) escribió: > Hi, > > I was asked by a list member to provide feedback regarding the use of > gvSIG in a production environment. He communicated to me directly so the > list was not privy to the conversation. I respect his wishes not to have > the conversation on record but I would prefer to throw my observations > down so everyone can contribute/criticize/comment and the developers can > identify future priorities. Without going into the full conversation the > following points were *made by me* regarding gvSIG. I have highlighted > some salient points. > >1. I have been using gvSIG as my primary GIS package since about > October 2009, or at least when the stable release of gvSIG 1.9 (BN > 1253) was released. >2. As you will of noted I made comment on the list early in this > period that gvSIG+Sextante was the first OS GIS that allowed me to > complete my normal workflow without either resorting to the use of > ArcView or other OS packages. >3. Since then I have completed 2 'typical' projects and 1 'quite > large' and challenging project (the largest and most complicated > in my biennial calendar) and gvSIG has provided a robust > relatively stable GIS system. >4. You would have noted that the armada of posts on the server. These > are feedback as I push the limits of the package. Feedback I hope > will be valuable to developers and will result in an overall > improvement to the package. >5. In comparison to the pseudo standard - ArcView 3 - gvSIG is > comparable or excels in its functionality. The only area that > still a few glitches is the map routine; does maps quite well but > some combinations throw it into a spin. These problems are > transient however and no data to date have been lost. >6. The only problem I have encountered that has caused data > corruption (and I really tried hard to get this to happen after I > noted a couple of glitches) was editing an instance of a file > represented multiple times within the same view. *In theory, gvSIG > should prevent this from happening (i.e. editing this file without > first closing the other instances being used by gvSIG).* That > said, on review of all the other GIS packages and ArcView 3, I > note that they also do nothing to achieve an exclusive file lock > when editing a file. >7. I tested gvSIG 1.1.2 a while ago and decided it was not suitable > for my needs. When the Beta for 1.9 became available I found it > had the functionality but crashed doing simple things (=good to > play with, bad to use in production). Once the stable version of > gvSIG was released I found it did ~70% of what I needed but when > combined with Sextante did 95% of what I needed and a whole bunch > more that I only wish I had the capability of doing (spacial > analysis, image classification, etc). >8. After several months using gvSIG v1.9 (BN 1253) *I have drawn the > conclusion that the program is suitable for a prod
