Re: [gdal-dev] Blue artifact dots in shadows when using GDAL to create mosaics
On Wednesday, 29 September 2021 9:37:57 AM AEST Chastain, Raymond Lee (MU- Student) wrote: > Process is very simple > > 1. Take our tiles and build a virtual raster: > gdalbuildvrt -r lanczos -resolution HIGHEST output.vrt -input_file_list > input_file_list.txt 2. Convert our virtual raster to a GeoTIFF: > 3. gdal_translate -of GTIFF ./output.vrt ./output.tif I manually removed the NODATA part from the vrt, and it looks better. Possibly the nodata value in the source is bad? Or you need to put something more meaningful behind the images... Brad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Blue artifact dots in shadows when using GDAL to create mosaics
Process is very simple 1. Take our tiles and build a virtual raster: gdalbuildvrt -r lanczos -resolution HIGHEST output.vrt -input_file_list input_file_list.txt 2. Convert our virtual raster to a GeoTIFF: 3. gdal_translate -of GTIFF ./output.vrt ./output.tif The artifacts occur with all resolution methods (nearest, bilinear, cubic, cubicspline, lanczos, average, mode) to varying degrees. It appears to worsen when more and more tiles overlay a location and when more scaling is needed. I can provide a sample case that reproduces this: Public Drive Link to archive: https://drive.google.com/file/d/1Tu4_A5NLiG0CQytuIQeeqr6JOVdAZDqu/view?usp=sharing Archive contains 6 files: img_1.tif - A low resolution (1m) GTIFF image to be rendered behind the second image. img_2.tif - A high resolution (0.3m) GTIFF image to be rendered above the first image. output.vrt - The VRT we generated using the above command from Step 1. our_output.tif - The GTIFF mosaic generated using the above gdal_translate command from Step 2. blue_dots_in_our_output.png - A zoomed in screenshot of some of the blue dots in the sample (the blue dots in this sample are unfortunately minor compared to what we have seen in our un-shareable data) more_blue_dots_from_other_samples.png - A screenshot of some of the blue/yellow dots we see in some of our other samples which we cannot share. Other relevant information: * Attempted on GDAL 3.0.4, GDAL 3.2.1, and GDAL 3.2.3 Any help would be greatly appreciated, Raymond ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL installation on Docker not working anymore
I changed the Dockerfile following the same steps as the author of this
post (https://github.com/OSGeo/gdal/issues/4467) did to install GDAL (but
using version 2.2.3) and it worked fine. Still don't know why the way I did
previously is not working anymore but now everything is ok. Thank you!
Em seg., 27 de set. de 2021 às 11:38, Matheus Cammarosano Hidalgo <
matheuschida...@gmail.com> escreveu:
> The proposed solution applies to GDAL 3.0.4 going forward and I am working
> with 2.2.3. It is weird because I haven't changed anything in my
> Dockerfile...
>
> Em qui., 23 de set. de 2021 às 13:56, Even Rouault <
> even.roua...@spatialys.com> escreveu:
>
>> Perhaps related to https://github.com/OSGeo/gdal/issues/4467 ? where
>> upgrading setuptools was suggested
>> Le 23/09/2021 à 18:40, Matheus Cammarosano Hidalgo a écrit :
>>
>> I made a Dockerfile two years ago with a GDAL 2.2.3 install that was
>> working fine ultil three weeks ago, when I made a change in my Python code
>> (not Dockerfile), but when I tried to build the image I got an
>> error installing GDAL.
>> I am using a python:3.7 default image from Docker and I have the
>> following lines to install GDAL:
>> # Install GDAL dependencies
>> RUN apt-get install -y python3-pip libgdal-dev locales
>>
>> # Ensure locales configured correctly
>> RUN locale-gen en_US.UTF-8
>> ENV LC_ALL='en_US.utf8'
>>
>> # Set python aliases for python3
>> RUN echo 'alias python=python3' >> ~/.bashrc
>> RUN echo 'alias pip=pip3' >> ~/.bashrc
>>
>> # Update C env vars so compiler can find gdal
>> ENV CPLUS_INCLUDE_PATH=/usr/include/gdal
>> ENV C_INCLUDE_PATH=/usr/include/gdal
>>
>> RUN pip3 install GDAL==2.2.3
>>
>> When I try to build the image, I get the following error message:
>> ERROR: Command errored out with exit status 1: /usr/local/bin/python -u
>> -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] =
>> '"'"'/tmp/pip-install-9sbmiien/gdal_b1debd2d108d43f38c9919e931126904/setup.py'"'"';
>> __file__='"'"'/tmp/pip-install-9sbmiien/gdal_b1debd2d108d43f38c9919e931126904/setup.py'"'"';f
>> = getattr(tokenize, '"'"'open'"'"', open)(__file__) if
>> os.path.exists(__file__) else io.StringIO('"'"'from setuptools import
>> setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"',
>> '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))'
>> install --record /tmp/pip-record-sp2ip9vm/install-record.txt
>> --single-version-externally-managed --compile --install-headers
>> /usr/local/include/python3.7m/GDAL Check the logs for full command output.
>>
>> Does anyone know what is happening and some way to make the installation
>> work? Thank you!
>>
>> Best regards,
>> Matheus
>>
>> ___
>> gdal-dev mailing
>> listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> -- http://www.spatialys.com
>> My software is free, but my time generally not.
>>
>>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Does OAPIF paging work as supposed?
Le 28/09/2021 à 09:04, Rahkonen Jukka (MML) a écrit : Hi, Even Rouault wrote: > One option to avoid both issues would be for the service to publish > DescribedBy links at the collection level that would point to a XML > schema (using a GML Simple Feature schema profile, such as the one > understood by the GML driver) or a JSON schema (not "too" complicated too). > Both are handled by the driver. We added JSON schema and ogrinfo seems to read it, but it still wants to read one page of data: ah you're right. Yes, looking at the code it will always read one page. There might be missing information in the schema, in particular for the layer geometry type (not always filled in XML schema, and most likely never in JSON schema, or at least the logic for that isn't implemented). It also takes the opportunity to look at other things such as the numberMatched information to be able to response to GetFeatureCount(), although that could potentially be skipped and defered when it is invoked. ogrinfo OAPIF:http://some.internal.service/features/collections/PalstanSijaintitiedot/ -al -so -oo PAGE_SIZE=1 -nocount -noextent -nogeomtype --debug on HTTP: Fetch(http://some.internal.service /features/collections/PalstanSijaintitiedot/schema) HTTP: These HTTP headers were set: Accept: application/schema+json OAPIF: Using JSON schema HTTP: Fetch(http://some.internal.service /features/collections/PalstanSijaintitiedot/items?f=json=1) I wonder if there is still something in ogrinfo that I cannot turn off and what triggers the need to read some features, perhaps the coordinate system. -Jukka Rahkonen- -- http://www.spatialys.com My software is free, but my time generally not. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Does OAPIF paging work as supposed?
Hi, Even Rouault wrote: > One option to avoid both issues would be for the service to publish > DescribedBy links at the collection level that would point to a XML > schema (using a GML Simple Feature schema profile, such as the one > understood by the GML driver) or a JSON schema (not "too" complicated too). > Both are handled by the driver. We added JSON schema and ogrinfo seems to read it, but it still wants to read one page of data: ogrinfo OAPIF:http://some.internal.service/features/collections/PalstanSijaintitiedot/ -al -so -oo PAGE_SIZE=1 -nocount -noextent -nogeomtype --debug on HTTP: Fetch(http:// some.internal.service /features/collections/PalstanSijaintitiedot/schema) HTTP: These HTTP headers were set: Accept: application/schema+json OAPIF: Using JSON schema HTTP: Fetch(http:// some.internal.service /features/collections/PalstanSijaintitiedot/items?f=json=1) I wonder if there is still something in ogrinfo that I cannot turn off and what triggers the need to read some features, perhaps the coordinate system. -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
