[gdal-dev] Motion: Adopt RFC 41 : Support for multiple geometry fields in OGR
Hi, Motion: I move to adopt RFC 41 : Support for multiple geometry fields in OGR http://trac.osgeo.org/gdal/wiki/rfc41_multiple_geometry_fields I've made a few changes in the last few days. See the history : http://trac.osgeo.org/gdal/wiki/rfc41_multiple_geometry_fields?action=history Starting with my +1 Best regards, Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt RFC 41 : Support for multiple geometry fields in OGR
+1 Frank On Jul 29, 2013 4:14 AM, "Even Rouault" wrote: > Hi, > > Motion: I move to adopt RFC 41 : Support for multiple geometry fields in > OGR > > http://trac.osgeo.org/gdal/wiki/rfc41_multiple_geometry_fields > > I've made a few changes in the last few days. See the history : > > http://trac.osgeo.org/gdal/wiki/rfc41_multiple_geometry_fields?action=history > > Starting with my +1 > > Best regards, > > Even > > -- > Geospatial professional services > http://even.rouault.free.fr/services.html > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Working with NTF files
Nikos Alexandris: > > > I am trying to handle ntf files (NITF) as easy as possible -- working > > > with some WorldView 01/02 and QuickBird imagery. [..] > > > 2) A second, of less importance, question, is: how important are the > > > warnings like: "Warning 1: Unable to save auxilary information in > > > /vsisubfile/3884_471349721,10APR13WV020600013APR10075059- > > > P1BS-500060446050_05_P003.ntf.aux.xml." ? Frank W: > > This is not important. I presume you are getting this with JPEG2000 > > compressed image streams in NITF? Nikos A: > Correct > > If you file a bug I might be able to clear this up but there are layers of > > complexity that make it challening. > I will (take the time later to) file a ticket. Done as http://trac.osgeo.org/gdal/ticket/5173 Nikos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] [GRASS-user] Working with NTF files
Should I file for this a ticket in GRASS' trac first? Nikos --%<--- 1) Markus Metz wrote: > >> What says g.proj georef=your_geofile -p? Nikos Alexandris: > > g.proj -p georef=15JUN11IK0101000po_697515_pan_000.ntf > > Trying to open with OGR... > > ...succeeded. > > WARNING: Read of file 15JUN11IK0101000po_697515_pan_000.ntf was > > successful, but it did not contain projection information. 'XY > > (unprojected)' will be used XY location (unprojected) > > This is however 1) strange -- it misses a message like "Trying to open > > with GDAL..." and 2) (successively) not true because gdalinfo reports: Markus M: > g.proj first tries to open the geofile with OGR, if that fails, it > tries to open it with GDAL. Apparently OGR found a driver with which > it could successfully open the geofile. This might be a bug in OGR > (Frank?). Nikos A: > > Using this file in > > "grass7 -c 15JUN11IK0101000po_697515_pan_000.tif > > /grassdb/test_Location" > > creates the following Location: > > g.proj -p > > -PROJ_INFO- > > name : Lat/Lon > > proj : ll > > datum : wgs84 > > ellps : wgs84 > > no_defs : defined > > -PROJ_UNITS > > unit : degree > > units : degrees > > meters : 1.0 Markus M: > grass7 -c uses g.proj to create a location, thus the resulting > projection info of grass7 -c and g.proj georef= should be identical. 2) Markus M: > >> What reports r.in.gdal when trying to import in a location that > >> definitively does not match the SRS? Nikos A: > > Now, r.in.gdal seems to correctly recognise the SRS! Markus M: > Good. So it is either a bug in g.proj (even though the call to OGROpen() > succeeds) or in OGR. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Working with NTF files
A workaround to your 2nd question is to set the GDAL_PAM_PROXY_DIR environment variable, either permanently or on the commandline before you call gdalinfo. set GDAL_PAM_PROXY_DIR=%TEMP% gdalinfo -stats some.ntf -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-Working-with-NTF-files-tp5066312p5069520.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
