Problems with EPSG.21781
|
|
FANGER Lorenz
|
Hello List
I visited a course about gvSIG in Munich and was quite impressed how far the development of gvSIG has evolved. With 1.9 it wll be defenetly intersting for our company to use gvSIG insted of a closed source Desktop-GIS. How ever courrently the mayor problem with 1.9 (Build 1250) for us as a company based in switzerland is that the support of the swiss CRS is not given. Defining the CRS of a view with EPSG:21781 fails and returns the Error "java.lang.Exception: In proj4 Projection Oblique Mercator not admit azimut close to 90". Also loading data with defined CRS of EPSG:21781 into a view with CRS EPSG:4326 returns a "User error" If I remember well the 1.1 Versions once also had problems with swiss CRS. There the problem seems to be solved as the current stable versions do support swiss CRS Does anybody knows a feasable work arround for common user? Is it planed to solve that bug? How can we supoort a solution of that problem (without experiences in programming and projections)? I found a similar Mail in the List [1] from early this year but could not follow the mentioned "ugly hack". [1] http://n2.nabble.com/libJCRS-Error-while-choosing-EPSG-21781-CRS-CH1903-LV03-td2186767.html#a2186767 Freundliche Grüsse Lorenz Fanger --------------------------------------------------------- Lorenz Fanger Dipl. Natw. ETH & MSc (GIS) CSD Ingenieure und Geologen AG Rathaus, Postfach 34 7430 Thusis Tel. +41 (0)81 632 15 00 Fax +41 (0)81 632 15 01 e-mail: [hidden email] www.csd.ch _______________________________________________ Gvsig_internacional mailing list [hidden email] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional |
||||||||||||||||
Benjamin Ducke
|
The error message comes directly from the PROJ4 library which
gvSIG uses to reproject from one SRS into another. Unfortunately, PROJ4 documentation is quite horrible and fragmentary, so I could not get down to the root of this issues. There are, however some notes on the Swiss Mercator projection: ftp://ftp.remotesensing.org/proj/swiss.pdf It seems that +init=world:CH1903 is needed to initialize PROJ4 with that projection? Perhaps there is something that was overlooked when rewriting the SRS engine for 1.9? I think this needs fixing by the developers. In the meantime, you could use the new tools in gvSIG 1.9 to define a custom SRS. Just use the same parameters as EPSG 21781, expect that you need to set azimuth to something very close to 90.0 (like 89.9999, as suggested in the link you mentioned). Ben ----- Original Message ----- From: "FANGER Lorenz" <[hidden email]> To: "gvsig internacional" <[hidden email]> Sent: Wednesday, November 4, 2009 11:31:22 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: [Gvsig_english] Problems with EPSG.21781 Hello List I visited a course about gvSIG in Munich and was quite impressed how far the development of gvSIG has evolved. With 1.9 it wll be defenetly intersting for our company to use gvSIG insted of a closed source Desktop-GIS. How ever courrently the mayor problem with 1.9 (Build 1250) for us as a company based in switzerland is that the support of the swiss CRS is not given. Defining the CRS of a view with EPSG:21781 fails and returns the Error "java.lang.Exception: In proj4 Projection Oblique Mercator not admit azimut close to 90". Also loading data with defined CRS of EPSG:21781 into a view with CRS EPSG:4326 returns a "User error" If I remember well the 1.1 Versions once also had problems with swiss CRS. There the problem seems to be solved as the current stable versions do support swiss CRS Does anybody knows a feasable work arround for common user? Is it planed to solve that bug? How can we supoort a solution of that problem (without experiences in programming and projections)? I found a similar Mail in the List [1] from early this year but could not follow the mentioned "ugly hack". [1] http://n2.nabble.com/libJCRS-Error-while-choosing-EPSG-21781-CRS-CH1903-LV03-td2186767.html#a2186767 Freundliche Grüsse Lorenz Fanger --------------------------------------------------------- Lorenz Fanger Dipl. Natw. ETH & MSc (GIS) CSD Ingenieure und Geologen AG Rathaus, Postfach 34 7430 Thusis Tel. +41 (0)81 632 15 00 Fax +41 (0)81 632 15 01 e-mail: [hidden email] www.csd.ch _______________________________________________ Gvsig_internacional mailing list [hidden email] 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 [hidden email] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional |
Frank Warmerdam
|
Benjamin Ducke wrote:
> The error message comes directly from the PROJ4 library which > gvSIG uses to reproject from one SRS into another. > Unfortunately, PROJ4 documentation is quite horrible and fragmentary, > so I could not get down to the root of this issues. > There are, however some notes on the Swiss Mercator projection: > > ftp://ftp.remotesensing.org/proj/swiss.pdf > > It seems that +init=world:CH1903 is needed to initialize PROJ4 > with that projection? Perhaps there is something that was overlooked > when rewriting the SRS engine for 1.9? I think this needs fixing > by the developers. > > In the meantime, you could use the new tools in gvSIG 1.9 to define > a custom SRS. Just use the same parameters as EPSG 21781, expect > that you need to set azimuth to something very close to 90.0 > (like 89.9999, as suggested in the link you mentioned). Folks, I examined the current PROJ.4 epsg init file and for 21781 it uses: # CH1903 / LV03 <21781> +proj=somerc +lat_0=46.95240555555556 +lon_0=7.439583333333333 +k_0=1 +x_0=600000 +y_0=200000 +ellps=bessel +towgs84=674.374,15.056,405.346,0,0,0,0 +units=m +no_defs <> I have tried this and do not get the mentioned error. I believe there was an error in the epsg init file in some versions of PROJ.4 so replacing the <21781> entry in the init file will hopefully correct the issue till it is upgraded. Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up | Frank Warmerdam, [hidden email] light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush | Geospatial Programmer for Rent _______________________________________________ Gvsig_internacional mailing list [hidden email] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional |
||||||||||||||||
|
FANGER Lorenz
|
Hi List
Thanks for the answers. Well the hack with the user CRS works fine for shapes and wms but not for postgis-datas. With postgis-datas the following error was thrown in the information console: null java.nio.BufferUnderflowException: null java.nio.Buffer.nextGetIndex(Unknown Source) java.nio.HeapByteBuffer.getInt(Unknown Source com.iver.cit.gvsig.fmap.drivers.jdbc.postgis.PostGisDriver.getFieldValue(PostGisDriver.java:466) com.iver.cit.gvsig.fmap.drivers.jdbc.postgis.PostGisFeatureIterator.next(PostGisFeatureIterator.java:171 com.iver.cit.gvsig.fmap.drivers.featureiterators.ReprojectWrapperFeatureIterator.next(ReprojectWrapperFeatureIterator.java:92) com.iver.cit.gvsig.fmap.layers.FLyrVect._draw(FLyrVect.java:437) com.iver.cit.gvsig.fmap.layers.FLyrVect.draw(FLyrVect.java:631) com.iver.cit.gvsig.fmap.DefaultMapContextDrawer.draw(DefaultMapContextDrawer.java:209) com.iver.cit.gvsig.fmap.DefaultMapContextDrawer.draw(DefaultMapContextDrawer.java:175) com.iver.cit.gvsig.fmap.MapContext.draw(MapContext.java:1092) com.iver.cit.gvsig.fmap.MapControl$PaintingRequest.paint(MapControl.java:1043) com.iver.cit.gvsig.fmap.MapControl$Drawer2$Worker.run(MapControl.java:1234) java.lang.Thread.run(Unknown Source) Therefor I would like to check the hack from Frank. But as I'm new in that proj-stuff I have no idea where to find the PROJ.4 epsg init file. And is just enough to change the <21781> entry in that file and afterwards to restart the program? Thanks for helping a greenhorn. Freundliche Grüsse Lorenz Fanger --------------------------------------------------------- Lorenz Fanger Dipl. Natw. ETH & MSc (GIS) CSD Ingenieure und Geologen AG Rathaus, Postfach 34 7430 Thusis Tel. +41 (0)81 632 15 00 Fax +41 (0)81 632 15 01 e-mail: [hidden email] www.csd.ch > > Folks, > > I examined the current PROJ.4 epsg init file and for 21781 it uses: > > # CH1903 / LV03 > <21781> +proj=somerc +lat_0=46.95240555555556 > +lon_0=7.439583333333333 +k_0=1 > +x_0=600000 +y_0=200000 +ellps=bessel > ++towgs84=674.374,15.056,405.346,0,0,0,0 > +units=m +no_defs <> > > I have tried this and do not get the mentioned error. I > believe there was an error in the epsg init file in some > versions of PROJ.4 so replacing the <21781> entry in the init > file will hopefully correct the issue till it is upgraded. > > Best regards, > -- > ---------------------------------------+---------------------- > ---------- > ---------------------------------------+------ > I set the clouds in motion - turn up | Frank Warmerdam, > [hidden email] > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush | Geospatial > Programmer for Rent > > _______________________________________________ > Gvsig_internacional mailing list > [hidden email] > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional > Gvsig_internacional mailing list [hidden email] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional |
||||||||||||||||
Antonio Falciano
|
FANGER Lorenz ha scritto:
> Hi List > > Thanks for the answers. > > Well the hack with the user CRS works fine for shapes and wms but not for postgis-datas. With postgis-datas the following error was thrown in the information console: Hi all, it's very strange, the EPSG:21781 entry in PostGIS spatial_ref_sys table is the same reported by Frank. gvSIG 1.1.2 uses the whole db_epsg.script file located in <gvSIG_1.1.2_folder>\bin\gvSIG\extensiones\org.gvsig.crs, while gvSIG 1.9 uses only a part of EPSG db (by GeoTools EPSG HSQL Plugin [1]) caching only what the user needs and so I think it is possible to eventually make correction of the EPSG db only at code level (<gvSIG_1.9_folder>\bin\gvSIG\extensiones\com.iver.cit.gvsig\lib\geotools-epsg-hsql-2.1.1_gvsig.jar). What do developers think about this? Best regards, Antonio [1] http://docs.codehaus.org/display/GEOTDOC/EPSG+HSQL+Plugin -- Antonio Falciano http://www.linkedin.com/in/antoniofalciano _______________________________________________ Gvsig_internacional mailing list [hidden email] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional |
||||||||||||||||
Francisco José Peñarrubia-2
|
In reply to this post
by FANGER Lorenz
Hi Lorenz.
I think this is a different problem. The gvSIG driver is not reprojecting, so, I think the problem is not related with the kind of projection. I guess there is a problem with an Integer field in your table. Try to select only the geometry field for your layer in order to isolate the problem. To be sure about this problem, we need to connect to your data. Is it possible to do so? If yes, you can use my private mail, don't send the parameters to the whole list. Cheers. Fran Peñarrubia www.scolab.es FANGER Lorenz escribió: > Hi List > > Thanks for the answers. > > Well the hack with the user CRS works fine for shapes and wms but not for postgis-datas. With postgis-datas the following error was thrown in the information console: > > null > java.nio.BufferUnderflowException: null > java.nio.Buffer.nextGetIndex(Unknown Source) > java.nio.HeapByteBuffer.getInt(Unknown Source > com.iver.cit.gvsig.fmap.drivers.jdbc.postgis.PostGisDriver.getFieldValue(PostGisDriver.java:466) > com.iver.cit.gvsig.fmap.drivers.jdbc.postgis.PostGisFeatureIterator.next(PostGisFeatureIterator.java:171 > com.iver.cit.gvsig.fmap.drivers.featureiterators.ReprojectWrapperFeatureIterator.next(ReprojectWrapperFeatureIterator.java:92) com.iver.cit.gvsig.fmap.layers.FLyrVect._draw(FLyrVect.java:437) com.iver.cit.gvsig.fmap.layers.FLyrVect.draw(FLyrVect.java:631) com.iver.cit.gvsig.fmap.DefaultMapContextDrawer.draw(DefaultMapContextDrawer.java:209) com.iver.cit.gvsig.fmap.DefaultMapContextDrawer.draw(DefaultMapContextDrawer.java:175) com.iver.cit.gvsig.fmap.MapContext.draw(MapContext.java:1092) > com.iver.cit.gvsig.fmap.MapControl$PaintingRequest.paint(MapControl.java:1043) > com.iver.cit.gvsig.fmap.MapControl$Drawer2$Worker.run(MapControl.java:1234) > java.lang.Thread.run(Unknown Source) > > Therefor I would like to check the hack from Frank. But as I'm new in that proj-stuff I have no idea where to find the PROJ.4 epsg init file. And is just enough to change the <21781> entry in that file and afterwards to restart the program? Thanks for helping a greenhorn. > > Freundliche Grüsse > Lorenz Fanger > > --------------------------------------------------------- > Lorenz Fanger > Dipl. Natw. ETH & MSc (GIS) > > CSD Ingenieure und Geologen AG > Rathaus, Postfach 34 > 7430 Thusis > Tel. +41 (0)81 632 15 00 > Fax +41 (0)81 632 15 01 > e-mail: [hidden email] www.csd.ch > > > >> Folks, >> >> I examined the current PROJ.4 epsg init file and for 21781 it uses: >> >> # CH1903 / LV03 >> <21781> +proj=somerc +lat_0=46.95240555555556 >> +lon_0=7.439583333333333 +k_0=1 >> +x_0=600000 +y_0=200000 +ellps=bessel >> ++towgs84=674.374,15.056,405.346,0,0,0,0 >> +units=m +no_defs <> >> >> I have tried this and do not get the mentioned error. I >> believe there was an error in the epsg init file in some >> versions of PROJ.4 so replacing the <21781> entry in the init >> file will hopefully correct the issue till it is upgraded. >> >> Best regards, >> -- >> ---------------------------------------+---------------------- >> ---------- >> ---------------------------------------+------ >> I set the clouds in motion - turn up | Frank Warmerdam, >> [hidden email] >> light and sound - activate the windows | http://pobox.com/~warmerdam >> and watch the world go round - Rush | Geospatial >> Programmer for Rent >> >> _______________________________________________ >> Gvsig_internacional mailing list >> [hidden email] >> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional >> >> > _______________________________________________ > Gvsig_internacional mailing list > [hidden email] > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional > _______________________________________________ Gvsig_internacional mailing list [hidden email] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional |
||||||||||||||||
|
FANGER Lorenz
|
Thanks again for the inputs
Sorry I can't provide access to the Postgis-Datas as the server sits behind a firewall. If you like I can provide some file based version you can upload to the own server. However the input with the Integerfield helped me further. gvSIG obviously does not accept integer (int[4]) and longinteger (int[8]) field types of gid field. It works with smallint (int[2]) and i also tested successfully with some other field types like varchar, numeric etc... As int[4] and [8] are likely to be field types for gid fields this seems to me like a bug, which should be solved. How ever. EPSG:21781 remains not nativly supported by gvSIG 1.9 (build 1250). The hack with the user CRS is the only way I could handle that issue. Would be nice if that issue could be solved on the code level as Antonio has suggested. With that I look forward to introduce gvSIG in our company for common gis-user. Freundliche Grüsse Lorenz Fanger > -----Ursprüngliche Nachricht----- > Von: [hidden email] > [mailto:[hidden email]] Im > Auftrag von Francisco José Peñarrubia > Gesendet: Donnerstag, 12. November 2009 11:20 > An: Users and Developers mailing list > Betreff: Re: [Gvsig_english] Problems with EPSG.21781 > > Hi Lorenz. > > I think this is a different problem. The gvSIG driver is not > reprojecting, so, I think the problem is not related with the > kind of projection. > I guess there is a problem with an Integer field in your > table. Try to select only the geometry field for your layer > in order to isolate the problem. > > To be sure about this problem, we need to connect to your > data. Is it possible to do so? If yes, you can use my private > mail, don't send the parameters to the whole list. > > Cheers. > > Fran Peñarrubia > www.scolab.es > > FANGER Lorenz escribió: > > Hi List > > > > Thanks for the answers. > > > > Well the hack with the user CRS works fine for shapes and > wms but not for postgis-datas. With postgis-datas the > following error was thrown in the information console: > > > > null > > java.nio.BufferUnderflowException: null > > java.nio.Buffer.nextGetIndex(Unknown Source) > > java.nio.HeapByteBuffer.getInt(Unknown Source > > > com.iver.cit.gvsig.fmap.drivers.jdbc.postgis.PostGisDriver.getFieldVal > > ue(PostGisDriver.java:466) > > > com.iver.cit.gvsig.fmap.drivers.jdbc.postgis.PostGisFeatureIte > rator.next(PostGisFeatureIterator.java:171 > > > com.iver.cit.gvsig.fmap.drivers.featureiterators.ReprojectWrap > perFeatureIterator.next(ReprojectWrapperFeatureIterator.java:9 > 2) > com.iver.cit.gvsig.fmap.layers.FLyrVect._draw(FLyrVect.java:43 > 7) > com.iver.cit.gvsig.fmap.layers.FLyrVect.draw(FLyrVect.java:631 > ) > com.iver.cit.gvsig.fmap.DefaultMapContextDrawer.draw(DefaultMa > pContextDrawer.java:209) > com.iver.cit.gvsig.fmap.DefaultMapContextDrawer.draw(DefaultMa > pContextDrawer.java:175) > com.iver.cit.gvsig.fmap.MapContext.draw(MapContext.java:1092) > > > com.iver.cit.gvsig.fmap.MapControl$PaintingRequest.paint(MapCo > > > com.iver.cit.gvsig.fmap.MapControl$Drawer2$Worker.run(MapContr ol.java:1234) > > java.lang.Thread.run(Unknown Source) > > > > Therefor I would like to check the hack from Frank. But as > I'm new in that proj-stuff I have no idea where to find the > PROJ.4 epsg init file. And is just enough to change the > <21781> entry in that file and afterwards to restart the > program? Thanks for helping a greenhorn. > > > > Freundliche Grüsse > > Lorenz Fanger > > > > --------------------------------------------------------- > > Lorenz Fanger > > Dipl. Natw. ETH & MSc (GIS) > > > > CSD Ingenieure und Geologen AG > > Rathaus, Postfach 34 > > 7430 Thusis > > Tel. +41 (0)81 632 15 00 > > Fax +41 (0)81 632 15 01 > > e-mail: [hidden email] www.csd.ch > > > > > > > >> Folks, > >> > >> I examined the current PROJ.4 epsg init file and for 21781 it uses: > >> > >> # CH1903 / LV03 > >> <21781> +proj=somerc +lat_0=46.95240555555556 > >> +lon_0=7.439583333333333 +k_0=1 > >> +x_0=600000 +y_0=200000 +ellps=bessel > >> ++towgs84=674.374,15.056,405.346,0,0,0,0 > >> +units=m +no_defs <> > >> > >> I have tried this and do not get the mentioned error. I believe > >> there was an error in the epsg init file in some versions > of PROJ.4 > >> so replacing the <21781> entry in the init file will hopefully > >> correct the issue till it is upgraded. > >> > >> Best regards, > >> -- > >> ---------------------------------------+---------------------- > >> ---------- > >> ---------------------------------------+------ > >> I set the clouds in motion - turn up | Frank Warmerdam, > >> [hidden email] > >> light and sound - activate the windows | > http://pobox.com/~warmerdam > >> and watch the world go round - Rush | Geospatial > >> Programmer for Rent > >> > >> _______________________________________________ > >> Gvsig_internacional mailing list > >> [hidden email] > >> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional > >> > >> > > _______________________________________________ > > Gvsig_internacional mailing list > > [hidden email] > > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional > > > > _______________________________________________ > Gvsig_internacional mailing list > [hidden email] > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional > Gvsig_internacional mailing list [hidden email] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional |
||||||||||||||||
|
Francisco José Peñarrubia-2
|
Hi.
About ints, it is very strange... because I did some tests with integers and everything works. GID fields are used always, and even as a key to allow random access to features.... Is it possible that your PostgreSQL database is in a 64 bit operating system?. I haven't tryied yet this case. Cheers. Fran Peñarrubia www.scolab.es FANGER Lorenz escribió: > Thanks again for the inputs > > Sorry I can't provide access to the Postgis-Datas as the server sits behind a firewall. If you like I can provide some file based version you can upload to the own server. > > However the input with the Integerfield helped me further. gvSIG obviously does not accept integer (int[4]) and longinteger (int[8]) field types of gid field. It works with smallint (int[2]) and i also tested successfully with some other field types like varchar, numeric etc... As int[4] and [8] are likely to be field types for gid fields this seems to me like a bug, which should be solved. > > How ever. EPSG:21781 remains not nativly supported by gvSIG 1.9 (build 1250). The hack with the user CRS is the only way I could handle that issue. Would be nice if that issue could be solved on the code level as Antonio has suggested. With that I look forward to introduce gvSIG in our company for common gis-user. > > Freundliche Grüsse > Lorenz Fanger > > > > >> -----Ursprüngliche Nachricht----- >> Von: [hidden email] >> [mailto:[hidden email]] Im >> Auftrag von Francisco José Peñarrubia >> Gesendet: Donnerstag, 12. November 2009 11:20 >> An: Users and Developers mailing list >> Betreff: Re: [Gvsig_english] Problems with EPSG.21781 >> >> Hi Lorenz. >> >> I think this is a different problem. The gvSIG driver is not >> reprojecting, so, I think the problem is not related with the >> kind of projection. >> I guess there is a problem with an Integer field in your >> table. Try to select only the geometry field for your layer >> in order to isolate the problem. >> >> To be sure about this problem, we need to connect to your >> data. Is it possible to do so? If yes, you can use my private >> mail, don't send the parameters to the whole list. >> >> Cheers. >> >> Fran Peñarrubia >> www.scolab.es >> >> FANGER Lorenz escribió: >> >>> Hi List >>> >>> Thanks for the answers. >>> >>> Well the hack with the user CRS works fine for shapes and >>> >> wms but not for postgis-datas. With postgis-datas the >> following error was thrown in the information console: >> >>> null >>> java.nio.BufferUnderflowException: null >>> java.nio.Buffer.nextGetIndex(Unknown Source) >>> java.nio.HeapByteBuffer.getInt(Unknown Source >>> >>> >> com.iver.cit.gvsig.fmap.drivers.jdbc.postgis.PostGisDriver.getFieldVal >> >>> ue(PostGisDriver.java:466) >>> >>> >> com.iver.cit.gvsig.fmap.drivers.jdbc.postgis.PostGisFeatureIte >> rator.next(PostGisFeatureIterator.java:171 >> >> com.iver.cit.gvsig.fmap.drivers.featureiterators.ReprojectWrap >> perFeatureIterator.next(ReprojectWrapperFeatureIterator.java:9 >> 2) >> com.iver.cit.gvsig.fmap.layers.FLyrVect._draw(FLyrVect.java:43 >> 7) >> com.iver.cit.gvsig.fmap.layers.FLyrVect.draw(FLyrVect.java:631 >> ) >> com.iver.cit.gvsig.fmap.DefaultMapContextDrawer.draw(DefaultMa >> pContextDrawer.java:209) >> com.iver.cit.gvsig.fmap.DefaultMapContextDrawer.draw(DefaultMa >> pContextDrawer.java:175) >> com.iver.cit.gvsig.fmap.MapContext.draw(MapContext.java:1092) >> >> com.iver.cit.gvsig.fmap.MapControl$PaintingRequest.paint(MapCo >> > ntrol.java:1043) > >> com.iver.cit.gvsig.fmap.MapControl$Drawer2$Worker.run(MapContr >> > ol.java:1234) > >>> java.lang.Thread.run(Unknown Source) >>> >>> Therefor I would like to check the hack from Frank. But as >>> >> I'm new in that proj-stuff I have no idea where to find the >> PROJ.4 epsg init file. And is just enough to change the >> <21781> entry in that file and afterwards to restart the >> program? Thanks for helping a greenhorn. >> >>> Freundliche Grüsse >>> Lorenz Fanger >>> >>> --------------------------------------------------------- >>> Lorenz Fanger >>> Dipl. Natw. ETH & MSc (GIS) >>> >>> CSD Ingenieure und Geologen AG >>> Rathaus, Postfach 34 >>> 7430 Thusis >>> Tel. +41 (0)81 632 15 00 >>> Fax +41 (0)81 632 15 01 >>> e-mail: [hidden email] www.csd.ch >>> >>> >>> >>> >>>> Folks, >>>> >>>> I examined the current PROJ.4 epsg init file and for 21781 it uses: >>>> >>>> # CH1903 / LV03 >>>> <21781> +proj=somerc +lat_0=46.95240555555556 >>>> +lon_0=7.439583333333333 +k_0=1 >>>> +x_0=600000 +y_0=200000 +ellps=bessel >>>> ++towgs84=674.374,15.056,405.346,0,0,0,0 >>>> +units=m +no_defs <> >>>> >>>> I have tried this and do not get the mentioned error. I believe >>>> there was an error in the epsg init file in some versions >>>> >> of PROJ.4 >> >>>> so replacing the <21781> entry in the init file will hopefully >>>> correct the issue till it is upgraded. >>>> >>>> Best regards, >>>> -- >>>> ---------------------------------------+---------------------- >>>> ---------- >>>> ---------------------------------------+------ >>>> I set the clouds in motion - turn up | Frank Warmerdam, >>>> [hidden email] >>>> light and sound - activate the windows | >>>> >> http://pobox.com/~warmerdam >> >>>> and watch the world go round - Rush | Geospatial >>>> Programmer for Rent >>>> >>>> _______________________________________________ >>>> Gvsig_internacional mailing list >>>> [hidden email] >>>> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional >>>> >>>> >>>> >>> _______________________________________________ >>> Gvsig_internacional mailing list >>> [hidden email] >>> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional >>> >>> >> _______________________________________________ >> Gvsig_internacional mailing list >> [hidden email] >> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional >> >> > _______________________________________________ > Gvsig_internacional mailing list > [hidden email] > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional > _______________________________________________ Gvsig_internacional mailing list [hidden email] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional |
||||||||||||||||
|
FANGER Lorenz
|
Hi all
After several tests I' got a bit further... As I have Postgres-Testing environement on 32 and 64 bit systems the problems with the "ints" could not be this difference. After I installed the new stable version I got even a more sever error (java null pointer exception) when I tried to open a new view. I reinstalled GvSIg as well as my hole Java environment without solving the problem. Only after deleting the user gvSIG-directories (which are not removed by uninstalling gvSIG) and after reinstalling the programm again everything including loading postgis datas with different "int"-filed types and except the use of EPSG:21781 worked fine... Finally I look forward to start using gvSIG hopeing the things with EPSG:21781 will be resolved soon. Freundliche Grüsse Lorenz Fanger --------------------------------------------------------- Lorenz Fanger Dipl. Natw. ETH & MSc (GIS) CSD Ingenieure und Geologen AG Rathaus, Postfach 34 7430 Thusis Tel. +41 (0)81 632 15 00 Fax +41 (0)81 632 15 01 e-mail: [hidden email] www.csd.ch > -----Ursprüngliche Nachricht----- > Von: [hidden email] > [mailto:[hidden email]] Im > Auftrag von Francisco José Peñarrubia > Gesendet: Donnerstag, 12. November 2009 15:26 > An: Users and Developers mailing list > Betreff: Re: [Gvsig_english] Problems with EPSG.21781 > > Hi. > > About ints, it is very strange... because I did some tests > with integers and everything works. GID fields are used > always, and even as a key to allow random access to features.... > > Is it possible that your PostgreSQL database is in a 64 bit > operating system?. I haven't tryied yet this case. > > Cheers. > > Fran Peñarrubia > www.scolab.es > > FANGER Lorenz escribió: > > Thanks again for the inputs > > > > Sorry I can't provide access to the Postgis-Datas as the > server sits behind a firewall. If you like I can provide some > file based version you can upload to the own server. > > > > However the input with the Integerfield helped me further. > gvSIG obviously does not accept integer (int[4]) and > longinteger (int[8]) field types of gid field. It works with > smallint (int[2]) and i also tested successfully with some > other field types like varchar, numeric etc... As int[4] and > [8] are likely to be field types for gid fields this seems to > me like a bug, which should be solved. > > > > How ever. EPSG:21781 remains not nativly supported by gvSIG > 1.9 (build 1250). The hack with the user CRS is the only way > I could handle that issue. Would be nice if that issue could > be solved on the code level as Antonio has suggested. With > that I look forward to introduce gvSIG in our company for > common gis-user. > > > > Freundliche Grüsse > > Lorenz Fanger > > > > > > > > > >> -----Ursprüngliche Nachricht----- > >> Von: [hidden email] > >> [mailto:[hidden email]] Im > Auftrag von > >> Francisco José Peñarrubia > >> Gesendet: Donnerstag, 12. November 2009 11:20 > >> An: Users and Developers mailing list > >> Betreff: Re: [Gvsig_english] Problems with EPSG.21781 > >> > >> Hi Lorenz. > >> > >> I think this is a different problem. The gvSIG driver is not > >> reprojecting, so, I think the problem is not related with > the kind of > >> projection. > >> I guess there is a problem with an Integer field in your > table. Try > >> to select only the geometry field for your layer in order > to isolate > >> the problem. > >> > >> To be sure about this problem, we need to connect to your > data. Is it > >> possible to do so? If yes, you can use my private mail, don't send > >> the parameters to the whole list. > >> > >> Cheers. > >> > >> Fran Peñarrubia > >> www.scolab.es > >> > >> FANGER Lorenz escribió: > >> > >>> Hi List > >>> > >>> Thanks for the answers. > >>> > >>> Well the hack with the user CRS works fine for shapes and > >>> > >> wms but not for postgis-datas. With postgis-datas the > following error > >> was thrown in the information console: > >> > >>> null > >>> java.nio.BufferUnderflowException: null > >>> java.nio.Buffer.nextGetIndex(Unknown Source) > >>> java.nio.HeapByteBuffer.getInt(Unknown Source > >>> > >>> > >> > com.iver.cit.gvsig.fmap.drivers.jdbc.postgis.PostGisDriver.getFieldVa > >> l > >> > >>> ue(PostGisDriver.java:466) > >>> > >>> > >> com.iver.cit.gvsig.fmap.drivers.jdbc.postgis.PostGisFeatureIte > >> rator.next(PostGisFeatureIterator.java:171 > >> > >> com.iver.cit.gvsig.fmap.drivers.featureiterators.ReprojectWrap > >> perFeatureIterator.next(ReprojectWrapperFeatureIterator.java:9 > >> 2) > >> com.iver.cit.gvsig.fmap.layers.FLyrVect._draw(FLyrVect.java:43 > >> 7) > >> com.iver.cit.gvsig.fmap.layers.FLyrVect.draw(FLyrVect.java:631 > >> ) > >> com.iver.cit.gvsig.fmap.DefaultMapContextDrawer.draw(DefaultMa > >> pContextDrawer.java:209) > >> com.iver.cit.gvsig.fmap.DefaultMapContextDrawer.draw(DefaultMa > >> pContextDrawer.java:175) > >> com.iver.cit.gvsig.fmap.MapContext.draw(MapContext.java:1092) > >> > >> com.iver.cit.gvsig.fmap.MapControl$PaintingRequest.paint(MapCo > >> > > ntrol.java:1043) > > > >> com.iver.cit.gvsig.fmap.MapControl$Drawer2$Worker.run(MapContr > >> > > ol.java:1234) > > > >>> java.lang.Thread.run(Unknown Source) > >>> > >>> Therefor I would like to check the hack from Frank. But as > >>> > >> I'm new in that proj-stuff I have no idea where to find the > >> PROJ.4 epsg init file. And is just enough to change the > <21781> entry > >> in that file and afterwards to restart the program? Thanks for > >> helping a greenhorn. > >> > >>> Freundliche Grüsse > >>> Lorenz Fanger > >>> > >>> --------------------------------------------------------- > >>> Lorenz Fanger > >>> Dipl. Natw. ETH & MSc (GIS) > >>> > >>> CSD Ingenieure und Geologen AG > >>> Rathaus, Postfach 34 > >>> 7430 Thusis > >>> Tel. +41 (0)81 632 15 00 > >>> Fax +41 (0)81 632 15 01 > >>> e-mail: [hidden email] www.csd.ch > >>> > >>> > >>> > >>> > >>>> Folks, > >>>> > >>>> I examined the current PROJ.4 epsg init file and for > 21781 it uses: > >>>> > >>>> # CH1903 / LV03 > >>>> <21781> +proj=somerc +lat_0=46.95240555555556 > >>>> +lon_0=7.439583333333333 +k_0=1 > >>>> +x_0=600000 +y_0=200000 +ellps=bessel > >>>> ++towgs84=674.374,15.056,405.346,0,0,0,0 > >>>> +units=m +no_defs <> > >>>> > >>>> I have tried this and do not get the mentioned error. I believe > >>>> there was an error in the epsg init file in some versions > >>>> > >> of PROJ.4 > >> > >>>> so replacing the <21781> entry in the init file will hopefully > >>>> correct the issue till it is upgraded. > >>>> > >>>> Best regards, > >>>> -- > >>>> ---------------------------------------+---------------------- > >>>> ---------- > >>>> ---------------------------------------+------ > >>>> I set the clouds in motion - turn up | Frank Warmerdam, > >>>> [hidden email] > >>>> light and sound - activate the windows | > >>>> > >> http://pobox.com/~warmerdam > >> > >>>> and watch the world go round - Rush | Geospatial > >>>> Programmer for Rent > >>>> > >>>> _______________________________________________ > >>>> Gvsig_internacional mailing list > >>>> [hidden email] > >>>> > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> Gvsig_internacional mailing list > >>> [hidden email] > >>> > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional > >>> > >>> > >> _______________________________________________ > >> Gvsig_internacional mailing list > >> [hidden email] > >> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional > >> > >> > > _______________________________________________ > > Gvsig_internacional mailing list > > [hidden email] > > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional > > > > _______________________________________________ > Gvsig_internacional mailing list > [hidden email] > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional > Gvsig_internacional mailing list [hidden email] http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
