Re: [GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5
On Tue, 12 Mar 2019, Markus Metz wrote: Dear Roger, On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand wrote: Since rgdal::make_EPSG() is facing the same problems of listing tabulated EPSG fields as g.proj -l, I was very happy to see Markus' code in g.proj/main.c mentioned in this thread, and have used this approach in https://r-forge.r-project.org/scm/viewvc.php/pkg/src/proj_info6.cpp?view=markup=rgdal However, there are plenty of messages such as: "proj_as_proj_string: Unsupported conversion method: Lambert Conic Conformal (West Orientated)". I haven't installed GRASS trunk with PROJ6, so I can't see whether g.proj -l also sees the same messages. If it does, maybe we could ask on the proj list how they might be captured for summary reporting. I think they are coming from line 5758 in src/iso19111/coordinateoperation.cpp or maybe line 906 in same file. Maybe PROJ now has an error handler that Another question concerns the issue of whether one needs to free objects created, in particular proj_crs_info and pj. Not so important for g.proj, which exists when done, but important for rgdal whose functions don't exit. Anyway, very helpful to see that Markus is looking at the same issues as we are! Regarding parsing the traditional PROJ init files, I looked at pj_init.c in PROJ 5 and earlier and attempted to improve parsing those traditional init files in GRASS trunk r74224. I guess that R as well as GRASS is trying to support PROJ versions from 4(.8) onwards. Thanks for letting me know where to look, I'll add this to our list of hints (Edzer is shepherding the sf package). And yes, we keep getting bitten by our bugs upsetting users of PROJ 4.8.0; Edzer was trying to set up check instances, but there is always something (recently stale proj.pc files reporting the wrong PROJ version). Best wishes, Roger Regards, Markus M -- Roger Bivand Department of Economics, Norwegian School of Economics, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no https://orcid.org/-0003-2392-6140 https://scholar.google.no/citations?user=AWeghB0J=en ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5
Dear Roger, On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand wrote: > > Since rgdal::make_EPSG() is facing the same problems of listing tabulated > EPSG fields as g.proj -l, I was very happy to see Markus' code in > g.proj/main.c mentioned in this thread, and have used this approach in > https://r-forge.r-project.org/scm/viewvc.php/pkg/src/proj_info6.cpp?view=markup=rgdal > > However, there are plenty of messages such as: "proj_as_proj_string: > Unsupported conversion method: Lambert Conic Conformal (West Orientated)". I > haven't installed GRASS trunk with PROJ6, so I can't see whether g.proj -l > also sees the same messages. If it does, maybe we could ask on the proj list > how they might be captured for summary reporting. I think they are coming > from line 5758 in src/iso19111/coordinateoperation.cpp or maybe line 906 in > same file. Maybe PROJ now has an error handler that > > Another question concerns the issue of whether one needs to free objects > created, in particular proj_crs_info and pj. Not so important for g.proj, > which exists when done, but important for rgdal whose functions don't exit. > > Anyway, very helpful to see that Markus is looking at the same issues as we > are! Regarding parsing the traditional PROJ init files, I looked at pj_init.c in PROJ 5 and earlier and attempted to improve parsing those traditional init files in GRASS trunk r74224. I guess that R as well as GRASS is trying to support PROJ versions from 4(.8) onwards. Regards, Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5
On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand wrote: > > Since rgdal::make_EPSG() is facing the same problems of listing tabulated > EPSG fields as g.proj -l, I was very happy to see Markus' code in > g.proj/main.c mentioned in this thread, and have used this approach in > https://r-forge.r-project.org/scm/viewvc.php/pkg/src/proj_info6.cpp?view=markup=rgdal > > However, there are plenty of messages such as: "proj_as_proj_string: > Unsupported conversion method: Lambert Conic Conformal (West Orientated)". I > haven't installed GRASS trunk with PROJ6, so I can't see whether g.proj -l > also sees the same messages. I get the same messages with g.proj, but no error code from PROJ error handlers. > If it does, maybe we could ask on the proj list yes, we should ask. For now g.proj is ignoring those codes for which no proj string can be retrieved. Markus M > how they might be captured for summary reporting. I think they are coming > from line 5758 in src/iso19111/coordinateoperation.cpp or maybe line 906 in > same file. Maybe PROJ now has an error handler that > > Another question concerns the issue of whether one needs to free objects > created, in particular proj_crs_info and pj. Not so important for g.proj, > which exists when done, but important for rgdal whose functions don't exit. > > Anyway, very helpful to see that Markus is looking at the same issues as we > are! > > Roger > > > > > > - > Roger Bivand > NHH Norwegian School of Economics, Bergen, Norway > -- > Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5
Since rgdal::make_EPSG() is facing the same problems of listing tabulated EPSG fields as g.proj -l, I was very happy to see Markus' code in g.proj/main.c mentioned in this thread, and have used this approach in https://r-forge.r-project.org/scm/viewvc.php/pkg/src/proj_info6.cpp?view=markup=rgdal However, there are plenty of messages such as: "proj_as_proj_string: Unsupported conversion method: Lambert Conic Conformal (West Orientated)". I haven't installed GRASS trunk with PROJ6, so I can't see whether g.proj -l also sees the same messages. If it does, maybe we could ask on the proj list how they might be captured for summary reporting. I think they are coming from line 5758 in src/iso19111/coordinateoperation.cpp or maybe line 906 in same file. Maybe PROJ now has an error handler that Another question concerns the issue of whether one needs to free objects created, in particular proj_crs_info and pj. Not so important for g.proj, which exists when done, but important for rgdal whose functions don't exit. Anyway, very helpful to see that Markus is looking at the same issues as we are! Roger - Roger Bivand NHH Norwegian School of Economics, Bergen, Norway -- Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5
Markus Metz: The GUI is now (r74175) no longer reading the file share/proj/epsg which no longer exists in PROJ 6, instead it uses g.proj list_codes=EPSG to get the list of EPSG codes. This is important e.g. for the location wizard to provide a list of known EPSG codes. Obviously, this works also in the TUI (aka the command line) and looks great! → g.proj list_codes=EPSG |grep 2100 2100|GGRS87 / Greek Grid|+proj=tmerc +lat_0=0 +lon_0=24 +k=0.9996 +x_0=50 +y_0=0 +datum=GGRS87 +units=m +no_defs 3035|ETRS89 / LAEA Europe|+proj=laea +lat_0=52 +lon_0=10 +x_0=4321000 +y_0=321 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs 5633|PTRA08 / LAEA Europe|+proj=laea +lat_0=52 +lon_0=10 +x_0=4321000 +y_0=321 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs 5635|REGCAN95 / LAEA Europe|+proj=laea +lat_0=52 +lon_0=10 +x_0=4321000 +y_0=321 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs 5636|TUREF / LAEA Europe|+proj=laea +lat_0=52 +lon_0=10 +x_0=4321000 +y_0=321 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs 5638|ISN2004 / LAEA Europe|+proj=laea +lat_0=52 +lon_0=10 +x_0=4321000 +y_0=321 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs 32100|NAD83 / Montana|+proj=lcc +lat_1=49 +lat_2=45 +lat_0=44.25 +lon_0=-109.5 +x_0=60 +y_0=0 +datum=NAD83 +units=m +no_defs Thanks ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5
On Thu, Mar 7, 2019 at 5:17 PM Markus Metz wrote: > > > > On Mon, Feb 25, 2019 at 9:42 PM Even Rouault wrote: > > > > On lundi 25 février 2019 15:10:10 CET Markus Metz wrote: > > > Hi all, > > > > > > GRASS needs some adjustments in order to be compatible with PROJ 6 + GDAL > > > 2.5 > > > > > > The plain text file "share/proj/epsg" no longer exists. This file is > > > currently required by the GUI location wizard to retrieve a list of known > > > EPSG codes. Now there is a sqlite db "proj.db", and a new PROJ function > > > proj_get_codes_from_database(). I suggest to enhance g.proj with a new > > > option "list_codes_auth" which will print a list of codes for the given > > > autority name (EPSG, IGNF, etc.). This option can be made backwards > > > compatible to read "share/proj/epsg" with PROJ versions up to 5. The > > > location wizard can then use this new output of g.proj to construct a list > > > of known EPSG codes. > > > > If you want to do a nice GUI, proj_get_crs_info_list_from_database() is an > > enhanced version of proj_get_codes_from_database(), that will retrieve > > more information besides the code: name, area of use, type of CRS (geographic, > > projected, compound, etc...) > > in a very fast way (you can do the same with proj_get_codes_from_database(), > > and constructing a CRS for each code, but this is slower) > > Thanks for the hint! > > I have added a new option list_codes to g.proj that will print codes, names, and proj definitions for the given authority in trunk r74174. This new option works with PROJ 4, 5, and 6. Unfortunately it does not work yet with PROJ 4 because new fns have been added to the old proj_api.h... Markus M > > The GUI is now (r74175) no longer reading the file share/proj/epsg which no longer exists in PROJ 6, instead it uses g.proj list_codes=EPSG to get the list of EPSG codes. This is important e.g. for the location wizard to provide a list of known EPSG codes. > > The GUI in GRASS 7.6 is still trying to read share/proj/epsg and thus not compatible with PROJ 6. > > There are other authorities besides EPSG, these are supported with g.proj list_codes= if compiled against PROJ 6. Maybe we should support them too. > > I will look at the issues mentioned below in the next few days, should not be too much work I hope. > > Markus M > > > > > > > > We need to take care of axis order if a CRS is created from EPSG because > > > the axis order can now be northing, easting instead of traditional easting, > > > northing. Maybe it is enough to enforce +axis=enu, > > > > You can only use this if you use a PROJ string when invokating > > proj_create_crs_to_crs(), and this is the default axis order for PROJ string anyway. > > > > > or to use GDAL's > > > SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER) > > > > Yes, if you use GDAL OGRSpatialReference this is the way to go. > > > > If you don't use GDAL SRS and just PROJ API, you might also just reuse > > https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L298 > > > > which is called for the source and target CRS of the PJ object created > > with proj_create_crs_to_crs() > > https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L357 > > > > Even > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5
On Mon, Feb 25, 2019 at 9:42 PM Even Rouault wrote: > > On lundi 25 février 2019 15:10:10 CET Markus Metz wrote: > > Hi all, > > > > GRASS needs some adjustments in order to be compatible with PROJ 6 + GDAL > > 2.5 > > > > The plain text file "share/proj/epsg" no longer exists. This file is > > currently required by the GUI location wizard to retrieve a list of known > > EPSG codes. Now there is a sqlite db "proj.db", and a new PROJ function > > proj_get_codes_from_database(). I suggest to enhance g.proj with a new > > option "list_codes_auth" which will print a list of codes for the given > > autority name (EPSG, IGNF, etc.). This option can be made backwards > > compatible to read "share/proj/epsg" with PROJ versions up to 5. The > > location wizard can then use this new output of g.proj to construct a list > > of known EPSG codes. > > If you want to do a nice GUI, proj_get_crs_info_list_from_database() is an > enhanced version of proj_get_codes_from_database(), that will retrieve > more information besides the code: name, area of use, type of CRS (geographic, > projected, compound, etc...) > in a very fast way (you can do the same with proj_get_codes_from_database(), > and constructing a CRS for each code, but this is slower) Thanks for the hint! I have added a new option list_codes to g.proj that will print codes, names, and proj definitions for the given authority in trunk r74174. This new option works with PROJ 4, 5, and 6. The GUI is now (r74175) no longer reading the file share/proj/epsg which no longer exists in PROJ 6, instead it uses g.proj list_codes=EPSG to get the list of EPSG codes. This is important e.g. for the location wizard to provide a list of known EPSG codes. The GUI in GRASS 7.6 is still trying to read share/proj/epsg and thus not compatible with PROJ 6. There are other authorities besides EPSG, these are supported with g.proj list_codes= if compiled against PROJ 6. Maybe we should support them too. I will look at the issues mentioned below in the next few days, should not be too much work I hope. Markus M > > > > > We need to take care of axis order if a CRS is created from EPSG because > > the axis order can now be northing, easting instead of traditional easting, > > northing. Maybe it is enough to enforce +axis=enu, > > You can only use this if you use a PROJ string when invokating > proj_create_crs_to_crs(), and this is the default axis order for PROJ string anyway. > > > or to use GDAL's > > SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER) > > Yes, if you use GDAL OGRSpatialReference this is the way to go. > > If you don't use GDAL SRS and just PROJ API, you might also just reuse > https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L298 > > which is called for the source and target CRS of the PJ object created > with proj_create_crs_to_crs() > https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L357 > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5
On lundi 25 février 2019 15:10:10 CET Markus Metz wrote: > Hi all, > > GRASS needs some adjustments in order to be compatible with PROJ 6 + GDAL > 2.5 > > The plain text file "share/proj/epsg" no longer exists. This file is > currently required by the GUI location wizard to retrieve a list of known > EPSG codes. Now there is a sqlite db "proj.db", and a new PROJ function > proj_get_codes_from_database(). I suggest to enhance g.proj with a new > option "list_codes_auth" which will print a list of codes for the given > autority name (EPSG, IGNF, etc.). This option can be made backwards > compatible to read "share/proj/epsg" with PROJ versions up to 5. The > location wizard can then use this new output of g.proj to construct a list > of known EPSG codes. If you want to do a nice GUI, proj_get_crs_info_list_from_database() is an enhanced version of proj_get_codes_from_database(), that will retrieve more information besides the code: name, area of use, type of CRS (geographic, projected, compound, etc...) in a very fast way (you can do the same with proj_get_codes_from_database(), and constructing a CRS for each code, but this is slower) > > We need to take care of axis order if a CRS is created from EPSG because > the axis order can now be northing, easting instead of traditional easting, > northing. Maybe it is enough to enforce +axis=enu, You can only use this if you use a PROJ string when invokating proj_create_crs_to_crs(), and this is the default axis order for PROJ string anyway. > or to use GDAL's > SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER) Yes, if you use GDAL OGRSpatialReference this is the way to go. If you don't use GDAL SRS and just PROJ API, you might also just reuse https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L298 which is called for the source and target CRS of the PJ object created with proj_create_crs_to_crs() https://github.com/pramsey/postgis/blob/svn-trunk-proj/liblwgeom/lwgeom_transform.c#L357 Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5
Hi, po 25. 2. 2019 v 15:10 odesílatel Markus Metz napsal: > GRASS needs some adjustments in order to be compatible with PROJ 6 + GDAL 2.5 > > The plain text file "share/proj/epsg" no longer exists. This file is > currently required by the GUI location wizard to retrieve a list of known > EPSG codes. Now there is a sqlite db "proj.db", and a new PROJ function > proj_get_codes_from_database(). I suggest to enhance g.proj with a new option > "list_codes_auth" which will print a list of codes for the given autority > name (EPSG, IGNF, etc.). This option can be made backwards compatible to read > "share/proj/epsg" with PROJ versions up to 5. The location wizard can then > use this new output of g.proj to construct a list of known EPSG codes. sounds like a good plan :-) Worth to create new enhancement ticket? Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5
Hi all, GRASS needs some adjustments in order to be compatible with PROJ 6 + GDAL 2.5 The plain text file "share/proj/epsg" no longer exists. This file is currently required by the GUI location wizard to retrieve a list of known EPSG codes. Now there is a sqlite db "proj.db", and a new PROJ function proj_get_codes_from_database(). I suggest to enhance g.proj with a new option "list_codes_auth" which will print a list of codes for the given autority name (EPSG, IGNF, etc.). This option can be made backwards compatible to read "share/proj/epsg" with PROJ versions up to 5. The location wizard can then use this new output of g.proj to construct a list of known EPSG codes. We need to take care of axis order if a CRS is created from EPSG because the axis order can now be northing, easting instead of traditional easting, northing. Maybe it is enough to enforce +axis=enu, or to use GDAL's SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER) when asking GDAL to construct a CRS definition from an EPSG code. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
