Re: [gdal-dev] gdalwarp -t_srs proj=utm
Forgot to mention, this is to reproject from lat/long to UTM. Thanks, Shawn From: gdal-dev [gdal-dev-boun...@lists.osgeo.org] on behalf of Gong, Shawn [shawn.g...@mdacorporation.com] Sent: September-05-19 5:12 PM To: gdal-dev@lists.osgeo.org Subject: [gdal-dev] gdalwarp -t_srs proj=utm Hi GDAL list, gdalwarp -t_srs '+proj=utm +zone=XX +datum=WGS84' source.tif result.tif Is there a way for GDAL to automatically figure out the Zone #, so I don't have to provide XX ? Thanks, Shawn This electronic correspondence, including any attachments, is intended solely for the use of the intended recipient(s) and may contain legally privileged, proprietary and/or confidential information. If you are not the intended recipient, please immediately notify the sender by reply e-mail and permanently delete all copies of this electronic correspondence and associated attachments. Any use, disclosure, dissemination, distribution or copying of this electronic correspondence and any attachments for any purposes that have not been specifically authorized by the sender is strictly prohibited. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdalwarp -t_srs proj=utm
Hi GDAL list, gdalwarp -t_srs '+proj=utm +zone=XX +datum=WGS84' source.tif result.tif Is there a way for GDAL to automatically figure out the Zone #, so I don't have to provide XX ? Thanks, Shawn This electronic correspondence, including any attachments, is intended solely for the use of the intended recipient(s) and may contain legally privileged, proprietary and/or confidential information. If you are not the intended recipient, please immediately notify the sender by reply e-mail and permanently delete all copies of this electronic correspondence and associated attachments. Any use, disclosure, dissemination, distribution or copying of this electronic correspondence and any attachments for any purposes that have not been specifically authorized by the sender is strictly prohibited. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR FileGDB driver: 'OBJECTID' not recognised as an available field
Hi,
I'm not sure if bForwardWhereToSourceLayer should not be set in this case,
since the special field FID in pszWHEREIn has already been replaced.
Or the OpenFileGDB driver should indeed expose OBJECTID as a column
according to #4253
Best regards,
Tamas
Even Rouault ezt írta (időpont: 2019. szept.
5., Cs, 13:13):
> On mercredi 4 septembre 2019 22:13:40 CEST Tamas Szekeres wrote:
> > Hi,
> >
> > It looks like the sql queries with -dialect "OGRSQL" doesn't seem to
> work
> > as expected. When I specify the FID in the where clause, it doesn't
> filter
> > anything. The same query is also described as a solution in the following
> > ticket https://trac.osgeo.org/gdal/ticket/4253 but I doubt if that
> works at
> > all.
> >
> > The code causing this problem is fairly generic (ogr_gensql.cpp)
> >
> > if( psSelectInfo->where_expr && pszDialect != nullptr &&
> > EQUAL(pszDialect, "OGRSQL") )
> > {
> > int nMinIndexForSpecialField =
> > poSrcLayer->GetLayerDefn()->GetFieldCount();
> > bForwardWhereToSourceLayer =
> > !OGRGenSQLResultsLayerHasSpecialField
> > (psSelectInfo->where_expr,
> > nMinIndexForSpecialField);
> > }
> > if (bForwardWhereToSourceLayer)
> > pszWHERE = CPLStrdup(pszWHEREIn);
> > else
> > pszWHERE = nullptr;
> >
> > In the "where" expression, the FID field is thanslated to OBJECTID and it
> > is now treated as a special field, therefore the "where" expression is
> not
> > being passed to the driver.
> >
> > I'm also unsure if that is a correct action to omit passing "where" to
> the
> > layer instead of providing an error message.
>
> Actually the where isn't completely discarded. It is set on the
> OGRGenSQLResultsLayer per
>
> if( !bForwardWhereToSourceLayer )
> OGRGenSQLResultsLayer::SetAttributeFilter( pszWHEREIn );
>
> around line 492
>
> The issue is that the GenSQL layer has no FID column set, and thus this
> filter
> fails. One could potentially set the FID Column name on it from the source
> layer, but that wouldn't be really appropriate in the case of JOIN. That
> said
> I see a poDstFeat->SetFID( poSrcFeat->GetFID() ); at line 1332 of
> TranslateFeature(), so...
>
> (there might have been other fixes since #4253 that have made this case
> broken)
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR FileGDB driver: 'OBJECTID' not recognised as an available field
On mercredi 4 septembre 2019 22:13:40 CEST Tamas Szekeres wrote:
> Hi,
>
> It looks like the sql queries with -dialect "OGRSQL" doesn't seem to work
> as expected. When I specify the FID in the where clause, it doesn't filter
> anything. The same query is also described as a solution in the following
> ticket https://trac.osgeo.org/gdal/ticket/4253 but I doubt if that works at
> all.
>
> The code causing this problem is fairly generic (ogr_gensql.cpp)
>
> if( psSelectInfo->where_expr && pszDialect != nullptr &&
> EQUAL(pszDialect, "OGRSQL") )
> {
> int nMinIndexForSpecialField =
> poSrcLayer->GetLayerDefn()->GetFieldCount();
> bForwardWhereToSourceLayer =
> !OGRGenSQLResultsLayerHasSpecialField
> (psSelectInfo->where_expr,
> nMinIndexForSpecialField);
> }
> if (bForwardWhereToSourceLayer)
> pszWHERE = CPLStrdup(pszWHEREIn);
> else
> pszWHERE = nullptr;
>
> In the "where" expression, the FID field is thanslated to OBJECTID and it
> is now treated as a special field, therefore the "where" expression is not
> being passed to the driver.
>
> I'm also unsure if that is a correct action to omit passing "where" to the
> layer instead of providing an error message.
Actually the where isn't completely discarded. It is set on the
OGRGenSQLResultsLayer per
if( !bForwardWhereToSourceLayer )
OGRGenSQLResultsLayer::SetAttributeFilter( pszWHEREIn );
around line 492
The issue is that the GenSQL layer has no FID column set, and thus this filter
fails. One could potentially set the FID Column name on it from the source
layer, but that wouldn't be really appropriate in the case of JOIN. That said
I see a poDstFeat->SetFID( poSrcFeat->GetFID() ); at line 1332 of
TranslateFeature(), so...
(there might have been other fixes since #4253 that have made this case
broken)
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2ogr
On mercredi 4 septembre 2019 18:33:13 CEST Reynolds, Scott wrote: > A quick look at the GDAL source in > gdal-3.0.1\ogr\ogrsf_frmts\aeronavfaa\ograeronavfaadatasource.cpp suggests > that the code is not processing the file format correctly and therefore not > identifying the file as a Daily DOF. I would try to fix it, but I can't > get PROJ to build on Windows using Visual Studio because CMake can't find > SQLite binary. You can fetch one of the last 4 SDKs listed at depending on your arch& compiler: http://gisinternals.com/sdk.php They contain PROJ and other dependencies. Or follow (and slightly adapt for paths) the build recipee at https://github.com/OSGeo/PROJ/blob/master/appveyor.yml#L24 Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
