On Mon, 14 Feb 2022, 14:11 Mark Johnson, wrote:
> You should try rebuild the SpatialIndex.
>
> Spatialite offers gpkgAddSpatialIndex for a new Index.
>
> For its own format there are repair functions.
>
>SQL functions reference list
>- spatialite-sql-latest.html
>
You should try rebuild the SpatialIndex.
Spatialite offers gpkgAddSpatialIndex for a new Index.
For its own format there are repair functions.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
See MSSQLSpatial - Microsoft SQL Server Spatial Database — GDAL
documentation
https://gdal.org/drivers/vector/mssqlspatial.html
The MS SQL Spatial driver passes SQL statements directly to MS SQL by
default, rather than evaluating them internally when using the ExecuteSQL()
call on the OGRDataSour
Would adding a '-gcp_file' as a input parameter, that would contain the
list of gcp's to be used, be considered useful?
Often the gcp list could be created programmaticly and saved to file, which
would simplify the use from a script.
Mark
___
gdal-dev m
(not sure if here is the right place for this)
The 'FDO Binary Geometry Format' link:
http://fdo.osgeo.org/files/fdo/docs/FDG_FDODevGuide/files/WSfacf1429558a55de8821c21057fbebc2b-789.htm
on page
https://trac.osgeo.org/fdo/wiki/FDORfc16
is no longer valid.
Resulting in:
Forbidden
You don't h
'FDO Geometry Format':
Am I reading the code correctly that 'FDO', at least in the case of a
Sqlite-Container, is read only?
GeoPackage-Vector creation with ogr2ogr:
That it not possible to retain the original Geometry-Column Name, but
either 'geom' of the value given with '-lco GEOMETRY_NAME=geo
export CXX=/usr/bin/c++
make install
did not resolve this problem.
The WARNING, with ' --tag=CXX /usr/bin/g++ -std=c++11"' still turns up
during setup.py.
gcc -pthread -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -fPIC -I../../port -I../../gcore -I../../alg
-I../../ogr/
>> Do you know where this ccache invokation comes from ? Both libtool and
non-libtool regular builds work for me with the python bindings
echo $CC shows nothing.
echo $CXX shows '/usr/bin/ccache /usr/bin/c++'
At some point in the last year I added 'ccache' for use with QGis.
For ./configure ther
since this only occurs durring the swig
portion.
When ' (cd swig; $(MAKE) install)' is commented out in the GNUmakefile
file, everything else runs and installs.
Mark Johnson, Berlin Germany
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Sorry, I overlooked the 'output filename to guess', while reading the PR
and title.
Mark
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> ogr2ogr output.gpkg input.shp Where would you read the Magic-Headers in
> this case?
Before the input file is opened.
Read the first 100 bytes, compare with known signatures
if ((memcmp (blob, tiff_signature_big, 4) == 0) &&
(memcmp (blob, tiff_signature_little, 4) == 0))
{
return type
.
//--
// https://en.wikipedia.org/wiki/List_of_file_signatures
// https://gist.github.com/navinpai/983632
// https://www.iana.org/assignments/media-types/media-types.xhtml
//--
Mark
the new sources.
This should create the tiles correctly, merging the 2 sources together and
numbering the tiles correctly based on the given extent.
Theoretically this should work.
Mark Johnson, Berlin Germany
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
This will do the same, just replace the EPSG code number:
gdal_translate -ot Float32 -a_srs EPSG:25833 ../xyz/390_5820.dhhn92.txt
../2007.390_5820.dhhn92.25833.tif
Mark
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/l
You must sort the data beforehand
- the y position must be sorted properly (ASC or DESC)
Standard linux sort program:
sort -k2 -n -k1 392_5810.xyz -o 392_5810.sort.xyz
(2nd column (y) as numeric, then first column (x) -o = output file
As a zip file you can also do:
unzip -p 390_5820.zip | sort
The main reason (at the time - over 4 years ago) was:
- that there was no write support for mbtiles then
(as you no doubt saw in the link you provided)
I just tried gdal_translate on a sample file and see:
- that it (seems) to support only 1 zoom level
> Warning 6: driver MBTiles does not suppo
the space needed on sdcard's for tiles-directories is very high and
slow
It was always the intention to incorporate this into gdal2tiles, but not
being a Python expert/fan, I was always hoping that someone could take this
over and maintain it.
Mark Johnson,
at you got)
What the meaning of is: SRC_METHOD=NO_GEOTRANSFORM
- no idea
But with a world file the expected result comes out.
Mark Johnson Berlin Germany
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
n Rouault
> #
> # Permission
>
> needs to be changed to:
> #!/bin/bash
> # Copyright (c) 2010, Brian Case
> # Copyright (c) 2010-2014, Even Rouault
> #
> # Permission
>
> to run without error.
Mark Johnson, Berlin Germany
Yes, that looks good.
But also adapting the pages that use -co NAME=VALUE
- such as http://www.gdal.org/gdal_translate.html
-co "NAME=VALUE":
Passes a creation option to the output format driver. Multiple
-co options may be listed. See format specific documentation for
legal creation options for
nformation would be useful
- while searching I saw a lot of reports of people receiving ecw file 'raw'
and wondering how to get it in
Once one knows it, it is easy
But it has be hours since I found this sample:
gdal_edit -mo DATUM=WGS84 -mo PROJ=GEODETIC -a_ullr 7 47 8 46 test.ecw
an
ge to Grayscale:
gdal_calc.py -A input.tif --A_band=1 -B input.tif --B_band=2 -C input.tif
--C_band=3 --outfile=result.tif --calc="A*0.2989+B*0.5870+C*0.1140"
Would it be something in this form?
Mark Johnson, Berlin, Germany
___
gdal-
ther Projections that use UTM
(srid NOT BETWEEN 32600 AND 32799) AND
(
(proj4text LIKE '+proj=utm +zone%')
)
)
ORDER BY proj4text;
-- 947 results
Mark Johnson
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Question 2 is now finished:
https://github.com/geopaparazzi/Spatialite-Tasks-with-Sql-Scripts/wiki/Project-1811-gdal_question-02
Short version:
gdal_rasterize -tr 0.475211759942328 0.475212956422887 -te 24800 20700
25800 21300 -ot Byte -init 192 -a_nodata 192 -burn 0 -burn 173 -burn 83
-sql "SEL
.area_rote_rathausturm_panorama.png
Mark Johnson, Berlin Germany
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
open an issue at
https://github.com/geopaparazzi/geopaparazzi/issues
Mark Johnson, Berlin Germany
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
26 matches
Mail list logo
