Hi Andre and Even,
thanks a lot for this clarification. Especially the last hint from Even
solved my issue, although widely using this syntax, I wasn't aware of the
subtle difference it makes.
Cheers and thanks, Michael
2018-03-07 23:13 GMT+01:00 Even Rouault :
> On
On mercredi 7 mars 2018 17:45:41 CET Andre Joost wrote:
> Am 07.03.18 um 11:50 schrieb Michael Schulz:
> > Dear devs,
> >
> > why is og2ogr using a grid shift file explicitely specified in the
> > proj4 string in the s_srs parameter and not when the same proj4 string is
> > in the system-wide
Jukka,
>
> I checked some .gpkg database that is created by FME with the
> validate_gpkg.py script. It gives this error:
>
> __main__.GPKGCheckException: Req 5: table stand has column
> standnumberextension of unexpected type TEXT ( 2 )
>
> Excerpt from the standard:
> TEXT{(maxchar_count)}
>
Hi,
I checked some .gpkg database that is created by FME with the validate_gpkg.py
script. It gives this error:
__main__.GPKGCheckException: Req 5: table stand has column standnumberextension
of unexpected type TEXT ( 2 )
Excerpt from the standard:
TEXT{(maxchar_count)}
Variable length string
Am 07.03.18 um 11:50 schrieb Michael Schulz:
Dear devs,
why is og2ogr using a grid shift file explicitely specified in the
proj4 string in the s_srs parameter and not when the same proj4 string is
in the system-wide proj4/epsg file?
This example gives correct projected results:
ogr2ogr -f
Hi Christophe,
What do you *expect or want* to happen with your images?
Are your 4326 image coordinates in -180° to +180° range (ie. the right
longitude is < the left); or do they go past +180°?
3857 is a projected coordinate system, so doesn't have a builtin concept of
wrapping. Some clients
Dear devs,
why is og2ogr using a grid shift file explicitely specified in the
proj4 string in the s_srs parameter and not when the same proj4 string is
in the system-wide proj4/epsg file?
This example gives correct projected results:
ogr2ogr -f 'ESRI Shapefile' target.shp -s_srs "+proj=tmerc