Re: [gdal-dev] Rectify TIFF: Difference between applied GCP and warped image
Bischof, Richard lgln.niedersachsen.de> writes: > > Hi Jukka, > > you're correct. ArcMap is doing the on-the-fly transformation with the dataset, I applied the gcps using > gdal_translate to. > With both gdal_warp and ArcMap Rectify I use second order polynomial. > > I also found, that some areas of my source image are cut out from the gdal_warp destination dataset. > Hi, I can't really help you but because I do not understand warping algorithms. If ArcMap and GDAL makes different output with 2nd order polynomial and with the same gcp set I can see three alternatives: 1) GDAL is wrong 2) ArcMap is wrong 3) There are different interpretations about what should happen and both are right, or wrong. I suppose that what GDAL is doing is written in https://trac.osgeo.org/gdal/browser/trunk/gdal/alg/gdaltransformer.cpp I fear we do not have the code used by ArcMap available for making a comparison. Can you simplify the case into a question like: With this gcp set, applied to an image of sixe xxx(W) by yyy(H) pixels, after 2nd order polynomial transformation with GDAL the source pixel (x1, y1) is moved into location (x2, y2) in pixel space, and (xxx(E), yyy(N)) in projected cooordinates in EPSG:. ArcMap moves this pixel into (x2', y2') (xxx'(E), yyy'(N)) and I think than one or the other is wrong. What do warping specialists think? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GeoTiff 16bit to 8bit with GDAL 11.x
Le jeudi 14 avril 2016 22:48:23, Christine Waigl a écrit : > Hi Even, > > Thanks so much for this quick and thorough response. The workaround made it > possible to fix my code, and I've extended it to multi-band GeoTIFF files > (my RGB composites) as > > gdal_translate -ot Byte -of vrt -b 1 -b 1 -b 2 -b 3 -scale_4 -scale_1 > -scale_2 -scale_3 infile.tif infile_8bit.vrt > gdal_translate -b 2 -b 3 -b 4 infile_8bit.vrt infile_8bit.tif You're likely to hit the bug again with the above. Rather try (basically band 4 of the VRT is the "junk band" ): gdal_translate -ot Byte -of vrt -b 1 -b 2 -b 3 -b 3 -scale_4 -scale_1 -scale_2 -scale_3 infile.tif infile_8bit.vrt gdal_translate -b 1 -b 2 -b 3 infile_8bit.vrt infile_8bit.tif > > Un grand merci! > > Chris > > > On Wed, Apr 13, 2016 at 1:32 PM, Even Rouault > > wrote: > > Le mercredi 13 avril 2016 22:26:45, Christine Waigl a écrit : > > > Hi all, > > > > > > I have been using the GDAL command line tools to pre-process various > > > > kinds > > > > > of remote sensing imagery datasets in GeoTIFF format. This includes > > > resampling 16 bit images (eg. from Landsat 8) to 8-bit and to combine > > > > bands > > > > > into RBG composites. > > > > > > In GDAL 11.4 (and previous 11.x that I tried), this doesn't work any > > > > more: > > > gdal_translate -ot Byte -scale [sceneID]_Bn.tif [sceneID]_8bit_Bn.tif > > > > > > I usually apply this to the already clipped RGB composites, but > > > digging deeper, even for single-band images what seems to be happening > > > is that > > > > the > > > > > -scale option doesn't correctly calculates the source range: > > >- If I use the command above, or with -scale_1, the whole output > > >file has a value 0 for each pixel > > >- If I use the "-b 1 -scale", the whole output file has a value 255 > > >at each pixel > > >- If I use "-scale src_min src_max" with a manually inserted src_min > > > > and > > > > >src_max, I get a reasonable result (though not necessarily identical > > > > to > > > > > the GDAL result with automatically calculated min and max. > > > > > > > > > What is driving me absolutely bonkers, though, is that *occasionally* > > > the command "-b 1 -scale" DOES produce a correct 8-bit file. It's not > > > reproducible, though: if I delete all 8bit files and re-run the script > > > > over > > > > > a whole set of 16 bit files, a whole different file may be resampled > > > correctly. > > > > > > With GDAL 2.0.2, my old script (written when GDAL was at 1.8.x on my > > > machine) seems to be working at the moment, but my main system is > > > > currently > > > > > at 11.4, and I have a reason not to upgrade right away. Is there a way > > > to make it work with 11.4? I could run gdalinfo first and extract min > > > and > > > > max > > > > > from the stats, and then feed this into gdal_translate, but I'd like to > > > avoid this path if possible. A test file (a file subsetted with > > > > > "gdal_translate -projwin... " from a whole Landsat 8 band) is here: > > http://www2.gi.alaska.edu/~cwaigl/images/LC80660142015170LGN00_B5_clip.ti > > f > > > > > (3.8 MB). > > > > Christine, > > > > Thanks for the report. Random issues are often a sign of uninitialized > > memory and running through Valgrind confirmed it. > > And it confirms that the issues exists in all versions starting with > > 1.11, so the fact > > that it runs with 2.0.2 is just luck. > > > > A workaround is to do the following. Be sure to put -scale_2 *before* > > -scale_1. And be sure to use -b 1 in the second > > gdal_translate as the band 2 scale/offset in the VRT might be junk. > > > > $ gdal_translate -b 1 -b 1 -scale_2 -scale_1 -ot byte > > LC80660142015170LGN00_B5_clip.tif out.vrt -of vrt > > $ gdal_translate -b 1 out.vrt out.tif > > > > Fixed per https://trac.osgeo.org/gdal/ticket/6455 . > > > > Even > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Rectify TIFF: Difference between applied GCP and warped image
Jukka, Richard, firstly, ESRI contracted the late John P Snyder, from USGS, to design and initially implement their projection tools. The team now maintaining and developing this code has a highly respected pedigree. Whilst mistakes *do* happen, I think the ESRI code will most likely be reliable. There may, of course, be issues of usage. There are a number of potential factors that also require consideration - some PC chipsets, for example, are still reputably unreliable for floating point maths! I would, however, expect such to affect both approaches equally and so, effectively, to cancel out. I am intrigued by the choice of Second Order polynomial. The vast majority of users do not need to consider such usage, so I guess a question for Richard is why - and whether he has bibliography (or a suitable DEM) supporting this choice for his context. Back in the days when it was deemed necessary for me to teach students the projection maths, I used to give them a 3rd order equation and an aerial photograph for which one specific area had just one GCP: the result was that this area was extruded from the main image in a rather dramatic fashion (it was visually fine with a First Order and nothing like as dramatic with a Second Order polynomial. To 'lose' data, as you describe, suggests that this portion is computing to NODATA: possibly indicating a GCP coding error. I think it would be sensible to back off this part of the specification for now, to see what impact it is having. Lastly, for now, how are your GCPs arranged? Do you have the 'standard five' of some introductory texts (eg four corners and centre)? Or do you have a more dense pattern? Are you using elevation control? If so, how does this relate to your GCPs (do your GCPs define breaks of slope, for example)? An excellent text, with well explained equations, for your purposes may be "Map Projection Transformation: Principles and Applications" by Qihe Yang, John P Snyder and Waldo R Tobler and published by Taylor & Francis in 2000. Snyder's introductions to map projections are generally available for download from USGS. Enjoy! Peter On 15 April 2016 at 08:27, Jukka Rahkonen < jukka.rahko...@maanmittauslaitos.fi> wrote: > Bischof, Richard lgln.niedersachsen.de> writes: > > > > > Hi Jukka, > > > > you're correct. ArcMap is doing the on-the-fly transformation with the > dataset, I applied the gcps using > > gdal_translate to. > > With both gdal_warp and ArcMap Rectify I use second order polynomial. > > > > I also found, that some areas of my source image are cut out from the > gdal_warp destination dataset. > > > > Hi, > > I can't really help you but because I do not understand warping algorithms. > If ArcMap and GDAL makes different output with 2nd order polynomial and > with > the same gcp set I can see three alternatives: > > 1) GDAL is wrong > 2) ArcMap is wrong > 3) There are different interpretations about what should happen and both > are > right, or wrong. > > I suppose that what GDAL is doing is written in > https://trac.osgeo.org/gdal/browser/trunk/gdal/alg/gdaltransformer.cpp > I fear we do not have the code used by ArcMap available for making a > comparison. > > Can you simplify the case into a question like: > With this gcp set, applied to an image of sixe xxx(W) by yyy(H) pixels, > after 2nd order polynomial transformation with GDAL the source pixel (x1, > y1) is moved into location (x2, y2) in pixel space, and (xxx(E), yyy(N)) in > projected cooordinates in EPSG:. > > ArcMap moves this pixel into (x2', y2') (xxx'(E), yyy'(N)) and I think than > one or the other is wrong. What do warping specialists think? > > -Jukka Rahkonen- > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Peter J Halls, PhD Student, Post-war Reconstruction and Development Unit (PRDU), University of York Snail mail: PRDU, Derwent College, University of York, Heslington, York YO10 5DD This message has the status of a private and personal communication ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Rectify TIFF: Difference between applied GCP and warped image
> An excellent text, with well explained equations, for your purposes > may be "Map Projection Transformation: Principles and Applications" by Qihe > Yang, John P Snyder and Waldo R Tobler and published by Taylor & Francis in > 2000. Snyder's introductions to map projections are generally available > for download from USGS. In that instance, map projections are not relevant since the warping done by Richard doesn't involve any. Without the source image and the ESRI generated image, it is difficult to assess if something is really wrong and how much both images are different. One difference shown from the gdalinfo reports is the selection of the output resolution (there's a recent ticket about that in Trac : https://trac.osgeo.org/gdal/ticket/6320), but that's more or less an arbitrary choice that shouldn't affect the georeferencing. Other differences could come from the way polynomial coefficients are computed. GDAL uses least square adjustment, but I guess everyone does that. I'm not aware of issues having been reported against the GDAL code with 2nd order polynomial (contrary to 3rd order where there are likely implementation issues). Regarding truncation of the input rather, this might be due to insufficient sampling step when walking along the edges of the input raster. Adding -wo SAMPLE_STEPS=x with x > 21 (for example to 100) might help, possibly with -wo SAMPLE_GRID=YES ( see http://www.gdal.org/structGDALWarpOptions.html#a0ed77f9917bb96c7a9aabd73d4d06e08 ). Having to use that is a sign that the warping involves non neglectable non- linear warping. Fine tuning of the target extent with -te is also a possibility. > > Enjoy! > > Peter > > On 15 April 2016 at 08:27, Jukka Rahkonen < > > jukka.rahko...@maanmittauslaitos.fi> wrote: > > Bischof, Richard lgln.niedersachsen.de> writes: > > > Hi Jukka, > > > > > > you're correct. ArcMap is doing the on-the-fly transformation with the > > > > dataset, I applied the gcps using > > > > > gdal_translate to. > > > With both gdal_warp and ArcMap Rectify I use second order polynomial. > > > > > > I also found, that some areas of my source image are cut out from the > > > > gdal_warp destination dataset. > > > > > > Hi, > > > > I can't really help you but because I do not understand warping > > algorithms. If ArcMap and GDAL makes different output with 2nd order > > polynomial and with > > the same gcp set I can see three alternatives: > > > > 1) GDAL is wrong > > 2) ArcMap is wrong > > 3) There are different interpretations about what should happen and both > > are > > right, or wrong. > > > > I suppose that what GDAL is doing is written in > > https://trac.osgeo.org/gdal/browser/trunk/gdal/alg/gdaltransformer.cpp > > I fear we do not have the code used by ArcMap available for making a > > comparison. > > > > Can you simplify the case into a question like: > > With this gcp set, applied to an image of sixe xxx(W) by yyy(H) pixels, > > after 2nd order polynomial transformation with GDAL the source pixel (x1, > > y1) is moved into location (x2, y2) in pixel space, and (xxx(E), yyy(N)) > > in projected cooordinates in EPSG:. > > > > ArcMap moves this pixel into (x2', y2') (xxx'(E), yyy'(N)) and I think > > than one or the other is wrong. What do warping specialists think? > > > > -Jukka Rahkonen- > > > > ___ > > gdal-dev mailing list > > gdal-dev@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] MBTiles Error
Hi, I've got several files of MBTiles format that are from the an external source. I'm using the 2.0.2 version of GDAL. When opened by the gdalinfo CLI tool or the MBTiles driver they all have the same errors: Error 1: Invalid value for 'bounds' metadata Error 1: Cannot find min and max tile numbers gdalinfo failed- unable to open... Other MBTiles files from the same publisher open just fine. Is there a way to fix or override this metadata? It looks like GDAL 2.2 will allow these parameters to be overridden, but I can't use a beta version in my product and the final release looks like it could be 4 months from now. Thanks for any help. Doug ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MBTiles Error
Le vendredi 15 avril 2016 15:34:59, Miller, Doug a écrit : > Hi, > > > > I've got several files of MBTiles format that are from the an external > source. I'm using the 2.0.2 version of GDAL. When opened by the gdalinfo > CLI tool or the MBTiles driver they all have the same errors: > > > > Error 1: Invalid value for 'bounds' metadata > > Error 1: Cannot find min and max tile numbers > > gdalinfo failed- unable to open... > > > > Other MBTiles files from the same publisher open just fine. > > > > Is there a way to fix or override this metadata? There was a too restrictive check for the latitude range (didn't accept latitude above 86 deg). One workaround might be to remove the bounds metadata item with : ogrinfo your.mbtiles -sql "DELETE FROM metadata WHERE name = 'bounds'" or alter the extent with ogrinfo your.mbtiles -sql "UPDATE metadata SET value = 'min_long,min_lat,max_long,max_lat' WHERE name = 'bounds'" (replace min_long,min_lat,max_long,max_lat by actual values) > > > > It looks like GDAL 2.2 will allow these parameters to be overridden, but I > can't use a beta version in my product and the final release looks like it > could be 4 months from now. GDAL 2.1.0 you mean ? It should be out hopefully by end of the month, with the first release candidate to be issued next monday. The MBTiles driver in it indeed improves the opening of some products that failed before. I'd still be interested in having access to one of those products that currently fail to confirm that it works fine with 2.1.0. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Shapefile to SQL Server
Hi,
I have a Java web app with a SQL Server database and I would like to add
support for importing shapefiles. The shapes will then be used to determine if
geographic locations we have defined in our system are within the areas defined
by the shapes.
I've gone down the path of using ogr2ogr from Java to connect to SQL Server and
load the shapefile. However, I'm getting an error on a particular file I will
need to load. I'm wondering if I'm missing an option on the command? Using a
different shapefile, it seems to work.
Here is the command and the error:
String[] cmd = {
"-overwrite",
"-f", "MSSQLSpatial",
"MSSQL:Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx",
"C:\\Users\\mcolbert\\Downloads\\UGRB_Ozone_NAA\\UGRB_Ozone_NAA.shp", // error
on this one
//
"C:\\Users\\mcolbert\\Downloads\\tl_2010_06_zcta510\\tl_2010_06_zcta510.shp",
// this one seems fine
"-lco", "GEOM_TYPE=geography",
"-lco", "GEOM_NAME=geog",
"-nln", "CM_SHAPE",
"--debug", "ON"
//,"-a_srs", "ESPG:4269"
};
ogr2ogr.main(cmd);
OGR:
OGROpen(C:\Users\mcolbert\Downloads\UGRB_Ozone_NAA\UGRB_Ozone_NAA.shp/003FFE40)
succeeded as ESRI Shapefile.
OGR_MSSQLSpatial:
EstablishSession(Connection:"Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx")
ODBC: SQLDriverConnect(DRIVER=SQL
Server;Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx)
OGR: OGROpen(MSSQL:Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx/0042C440)
succeeded as MSSQLSpatial.
MSSQLSpatial: DeleteLayer(cm_shape)
OGR_MSSQLSpatial: Using column ogr_fid as FID for table cm_shape.
ERROR 1: INSERT command for new feature failed. [Microsoft][ODBC SQL Server
Driver][SQL Server]A .NET Framework error occurred during execution of
user-defined routine or aggregate "geography":
System.FormatException: 24201: Latitude values must be between -90 and 90
degrees.
System.FormatException:
at Microsoft.SqlServer.Types.GeographyValidator.ValidatePoint(Double x,
Double y, Nullable`1 z, Nullable`1 m)
at Microsoft.SqlServer.Types.Validator.BeginFigure(Double x, Double y,
Nullable`1 z, Nullable`1 m)
at Microsoft.SqlServer.Types.Forw
Terminating translation prematurely after failed
translation of layer UGRB_Ozone_NAA (use -skipfailures to skip errors)
I'm assuming there is nothing unusual about the shapefile. The file is
available here:
http://deq.wyoming.gov/media/attachments/Air%20Quality/Winter%20Ozone/Nonattainment%20Information/2012_AQD_UGRB-Ozone-Nonattainment-Area-GIS-Shape-File.zip
Any help is appreciated.
Thanks,
Mike
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Shapefile to SQL Server
Hi,
Looks like you have invalid latitude values in the shapefile. Try creating
geometry type instead of geography.
Best regards,
Tamas
2016-04-15 17:06 GMT+02:00 Mike Colbert :
> Hi,
>
>
>
> I have a Java web app with a SQL Server database and I would like to add
> support for importing shapefiles. The shapes will then be used to
> determine if geographic locations we have defined in our system are within
> the areas defined by the shapes.
>
>
>
> I’ve gone down the path of using ogr2ogr from Java to connect to SQL
> Server and load the shapefile. However, I’m getting an error on a
> particular file I will need to load. I’m wondering if I’m missing an
> option on the command? Using a different shapefile, it seems to work.
>
>
>
> Here is the command and the error:
>
>
>
> String[] cmd = {
>
> "-overwrite",
>
> "-f", "MSSQLSpatial",
>
>
> "MSSQL:Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx",
>
>
> "C:\\Users\\mcolbert\\Downloads\\UGRB_Ozone_NAA\\UGRB_Ozone_NAA.shp", //
> error on this one
>
> //
> "C:\\Users\\mcolbert\\Downloads\\tl_2010_06_zcta510\\tl_2010_06_zcta510.shp",
> // this one seems fine
>
> "-lco", "GEOM_TYPE=geography",
>
> "-lco", "GEOM_NAME=geog",
>
> "-nln", "CM_SHAPE",
>
> "--debug", "ON"
>
> //,"-a_srs", "ESPG:4269"
>
> };
>
> ogr2ogr.main(cmd);
>
>
>
> OGR:
> OGROpen(C:\Users\mcolbert\Downloads\UGRB_Ozone_NAA\UGRB_Ozone_NAA.shp/003FFE40)
> succeeded as ESRI Shapefile.
>
> OGR_MSSQLSpatial:
> EstablishSession(Connection:"Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx")
>
> ODBC: SQLDriverConnect(DRIVER=SQL
> Server;Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx)
>
> OGR:
> OGROpen(MSSQL:Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx/0042C440)
> succeeded as MSSQLSpatial.
>
> MSSQLSpatial: DeleteLayer(cm_shape)
>
> OGR_MSSQLSpatial: Using column ogr_fid as FID for table cm_shape.
>
> ERROR 1: INSERT command for new feature failed. [Microsoft][ODBC SQL
> Server Driver][SQL Server]A .NET Framework error occurred during execution
> of user-defined routine or aggregate "geography":
>
>
>
> System.FormatException: 24201: Latitude values must be between -90 and 90
> degrees.
>
>
>
> System.FormatException:
>
>
>
>at Microsoft.SqlServer.Types.GeographyValidator.ValidatePoint(Double x,
> Double y, Nullable`1 z, Nullable`1 m)
>
>
>
>at Microsoft.SqlServer.Types.Validator.BeginFigure(Double x, Double y,
> Nullable`1 z, Nullable`1 m)
>
>
>
>at Microsoft.SqlServer.Types.Forw
>
> Terminating translation prematurely after failed
>
> translation of layer UGRB_Ozone_NAA (use -skipfailures to skip errors)
>
>
>
>
>
>
>
> I’m assuming there is nothing unusual about the shapefile. The file is
> available here:
>
>
> http://deq.wyoming.gov/media/attachments/Air%20Quality/Winter%20Ozone/Nonattainment%20Information/2012_AQD_UGRB-Ozone-Nonattainment-Area-GIS-Shape-File.zip
>
>
>
> Any help is appreciated.
>
>
>
> Thanks,
>
> Mike
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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] MBTiles Error
Even, I tried option #1 (ogrinfo your.mbtiles -sql "DELETE FROM metadata WHERE name = 'bounds'") and then it came up clean with "gdalinfo" and loaded into QGIS correctly. The bad files are property that I cannot share, but I would if I could. Thanks for the help, Doug From: Even Rouault Sent: Friday, April 15, 2016 9:53 AM To: gdal-dev@lists.osgeo.org Cc: Miller, Doug Subject: Re: [gdal-dev] MBTiles Error Le vendredi 15 avril 2016 15:34:59, Miller, Doug a écrit : > Hi, > > > > I've got several files of MBTiles format that are from the an external > source. I'm using the 2.0.2 version of GDAL. When opened by the gdalinfo > CLI tool or the MBTiles driver they all have the same errors: > > > > Error 1: Invalid value for 'bounds' metadata > > Error 1: Cannot find min and max tile numbers > > gdalinfo failed- unable to open... > > > > Other MBTiles files from the same publisher open just fine. > > > > Is there a way to fix or override this metadata? There was a too restrictive check for the latitude range (didn't accept latitude above 86 deg). One workaround might be to remove the bounds metadata item with : ogrinfo your.mbtiles -sql "DELETE FROM metadata WHERE name = 'bounds'" or alter the extent with ogrinfo your.mbtiles -sql "UPDATE metadata SET value = 'min_long,min_lat,max_long,max_lat' WHERE name = 'bounds'" (replace min_long,min_lat,max_long,max_lat by actual values) > > > > It looks like GDAL 2.2 will allow these parameters to be overridden, but I > can't use a beta version in my product and the final release looks like it > could be 4 months from now. GDAL 2.1.0 you mean ? It should be out hopefully by end of the month, with the first release candidate to be issued next monday. The MBTiles driver in it indeed improves the opening of some products that failed before. I'd still be interested in having access to one of those products that currently fail to confirm that it works fine with 2.1.0. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MBTiles Error
Le vendredi 15 avril 2016 18:27:55, Miller, Doug a écrit : > Even, > > I tried option #1 (ogrinfo your.mbtiles -sql "DELETE FROM metadata WHERE > name = 'bounds'") and then it came up clean with "gdalinfo" and loaded > into QGIS correctly. > > The bad files are property that I cannot share, but I would if I could. The output of the following would help : ogrinfo your.mbtiles -al -sql "SELECT value FROM metadata WHERE name = 'bounds'" > > Thanks for the help, > > Doug > > From: Even Rouault > Sent: Friday, April 15, 2016 9:53 AM > To: gdal-dev@lists.osgeo.org > Cc: Miller, Doug > Subject: Re: [gdal-dev] MBTiles Error > > Le vendredi 15 avril 2016 15:34:59, Miller, Doug a écrit : > > Hi, > > > > > > > > I've got several files of MBTiles format that are from the an external > > source. I'm using the 2.0.2 version of GDAL. When opened by the > > gdalinfo CLI tool or the MBTiles driver they all have the same errors: > > > > > > > > Error 1: Invalid value for 'bounds' metadata > > > > Error 1: Cannot find min and max tile numbers > > > > gdalinfo failed- unable to open... > > > > > > > > Other MBTiles files from the same publisher open just fine. > > > > > > > > Is there a way to fix or override this metadata? > > There was a too restrictive check for the latitude range (didn't accept > latitude above 86 deg). One workaround might be to remove the bounds > metadata item with : > > ogrinfo your.mbtiles -sql "DELETE FROM metadata WHERE name = 'bounds'" > > or alter the extent with > > ogrinfo your.mbtiles -sql "UPDATE metadata SET value = > 'min_long,min_lat,max_long,max_lat' WHERE name = 'bounds'" (replace > min_long,min_lat,max_long,max_lat by actual values) > > > It looks like GDAL 2.2 will allow these parameters to be overridden, but > > I can't use a beta version in my product and the final release looks > > like it could be 4 months from now. > > GDAL 2.1.0 you mean ? It should be out hopefully by end of the month, with > the first release candidate to be issued next monday. The MBTiles driver > in it indeed improves the opening of some products that failed before. > > I'd still be interested in having access to one of those products that > currently fail to confirm that it works fine with 2.1.0. > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Shapefile to SQL Server
The shape file in the zip is not in projection espg:4269. It's in utm
zone 12N. Replace the "-a_srs", "ESPG:4269" with "-t_srs", "ESPG:4269"
and "-s_srs", "ESPG: /code_for_UTM_12N/"
This causes ogr2ogr to reproject you data to the correct projection
Bo Victor Thomsen
Den 15/04/16 kl. 17:06 skrev Mike Colbert:
Hi,
I have a Java web app with a SQL Server database and I would like to
add support for importing shapefiles. The shapes will then be used to
determine if geographic locations we have defined in our system are
within the areas defined by the shapes.
I’ve gone down the path of using ogr2ogr from Java to connect to SQL
Server and load the shapefile. However, I’m getting an error on a
particular file I will need to load. I’m wondering if I’m missing an
option on the command? Using a different shapefile, it seems to work.
Here is the command and the error:
String[] cmd = {
"-overwrite",
"-f", "MSSQLSpatial",
"MSSQL:Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx",
"C:\\Users\\mcolbert\\Downloads\\UGRB_Ozone_NAA\\UGRB_Ozone_NAA.shp",
// error on this one
//
"C:\\Users\\mcolbert\\Downloads\\tl_2010_06_zcta510\\tl_2010_06_zcta510.shp",
// this one seems fine
"-lco", "GEOM_TYPE=geography",
"-lco", "GEOM_NAME=geog",
"-nln", "CM_SHAPE",
"--debug", "ON"
//,"-a_srs", "ESPG:4269"
};
ogr2ogr.main(cmd);
OGR:
OGROpen(C:\Users\mcolbert\Downloads\UGRB_Ozone_NAA\UGRB_Ozone_NAA.shp/003FFE40)
succeeded as ESRI Shapefile.
OGR_MSSQLSpatial:
EstablishSession(Connection:"Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx")
ODBC: SQLDriverConnect(DRIVER=SQL
Server;Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx)
OGR:
OGROpen(MSSQL:Server=xxx;Database=xxx;Uid=xxx;Pwd=xxx/0042C440) succeeded
as MSSQLSpatial.
MSSQLSpatial: DeleteLayer(cm_shape)
OGR_MSSQLSpatial: Using column ogr_fid as FID for table cm_shape.
ERROR 1: INSERT command for new feature failed. [Microsoft][ODBC SQL
Server Driver][SQL Server]A .NET Framework error occurred during
execution of user-defined routine or aggregate "geography":
System.FormatException: 24201: Latitude values must be between -90 and
90 degrees.
System.FormatException:
at
Microsoft.SqlServer.Types.GeographyValidator.ValidatePoint(Double x,
Double y, Nullable`1 z, Nullable`1 m)
at Microsoft.SqlServer.Types.Validator.BeginFigure(Double x, Double
y, Nullable`1 z, Nullable`1 m)
at Microsoft.SqlServer.Types.Forw
Terminating translation prematurely after failed
translation of layer UGRB_Ozone_NAA (use -skipfailures to skip errors)
I’m assuming there is nothing unusual about the shapefile. The file
is available here:
http://deq.wyoming.gov/media/attachments/Air%20Quality/Winter%20Ozone/Nonattainment%20Information/2012_AQD_UGRB-Ozone-Nonattainment-Area-GIS-Shape-File.zip
Any help is appreciated.
Thanks,
Mike
___
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] Shapefile to SQL Server
Bo Victor Thomsen gmail.com> writes: > > > The shape file in the zip is not in projection espg:4269. It's in > utm zone 12N. Replace the "-a_srs", "ESPG:4269" with "-t_srs", > "ESPG:4269" and "-s_srs", "ESPG: code_for_UTM_12N" > This causes ogr2ogr to reproject you data to the correct projection And it is written "EPSG" as in European Petroleum Survey Group. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Shapefile to SQL Server
I know, what the abbreviation "EPSG" stands for ! And I can't count the number of times I made this particular spelling mistake !! And four times in a row in one mail !!! At least it's weekend... Regards Bo Victor Den 15/04/16 kl. 20:16 skrev Jukka Rahkonen: Bo Victor Thomsen gmail.com> writes: The shape file in the zip is not in projection espg:4269. It's in utm zone 12N. Replace the "-a_srs", "ESPG:4269" with "-t_srs", "ESPG:4269" and "-s_srs", "ESPG: code_for_UTM_12N" This causes ogr2ogr to reproject you data to the correct projection And it is written "EPSG" as in European Petroleum Survey Group. -Jukka Rahkonen- ___ 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
