Re: [gdal-dev] Strange effect in gdalwarp output
Rutger, Thank you for your response. You are right, I think the best option is to run MRTswath for my data. I was looking for a practical way to avoid downloading geolocation files (MOD03) and get it done in python using the internally provided geolocation data and also avoid calling another application (MRTswath) from within python, but it seems that it is not an option. I will need to download all associated geolocation files for a couple of years. I tested MRTswath for the above mentioned sample and yes, the result is perfect. Regards, Mohamad -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Strange-effect-in-gdalwarp-output-tp5216470p5216531.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Compiling GDAL with MrSID support
Hi all,I'm having issues trying to compile GDAL with MrSID support. A preliminary question I have is: is MrSID write support available in GDAL, provided one has LizardTech's encoding SDK (ESDK)? The documentation is a bit confusing on this point, e.g. on this page http://www.gdal.org/formats_list.html MrSID creation support is denied, whereas on this page https://trac.osgeo.org/gdal/wiki/MrSID it is stated that it requires an ESDK. I have two versions of the MrSID SDK from LizardTech, Geo_ESDK-7.0.0.2167 (both encoding and decoding) and MrSID_DSDK-9.1.0.4045 (decoding only). The platform I'm building on is: CentOS 5.11 64-bit gcc 4.1.2 20080704 (Red Hat 4.1.2-55) I tried several versions of GDAL, 1.7.1, 1.7.3, 1.9.2, 2.0.0 but I keep getting the same error, when linking to Geo_ESDK-7.0.0.2167: g++ gdalinfo.o -L/root/gdal/gdal-1.7.1 -lgdal -ljpeg -ltiff -lpng -lz -lm -lrt -ldl -L/root/gdal/Geo_ESDK-7.0.0.2167/lib/Release -L/root/gdal/Geo_ESDK-7.0.0.2167/3rd-party/lib/Release -lltidsdk -lpthread -llt_kakadu -lxmlparse -o gdalinfo /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3MessageWriter::writeMessage(LizardTech::MG3Message)' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `QuantizeBuffer' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3VersionRequestMessage::MG3VersionRequestMessage()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3MessageWriter::initialize()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3DataRequestMessage::MG3DataRequestMessage()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3PacketRequestMessage::MG3PacketRequestMessage()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3DataReplyMessage::MG3DataReplyMessage(unsigned int, LizardTech::LTIOStreamInf*)' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3MSEReplyMessage::~MG3MSEReplyMessage()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3MessageReader::nextMessage()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3MSEReplyMessage::MG3MSEReplyMessage(unsigned int, LizardTech::LTIOStreamInf*)' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3MessageReader::initialize()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3PacketReplyMessage::MG3PacketReplyMessage(unsigned int, LizardTech::MG3PacketType const, LizardTech::MG3Packet*)' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3PlaneRangeDecoder::nextRange(unsigned long long, bool)' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3VersionRequestMessage::~MG3VersionRequestMessage()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MSEAdjuster::nominalMSE(LizardTech::MG3PlaneDesc const, LizardTech::MG3ImageInfo const)' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3DataRequestMessage::~MG3DataRequestMessage()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3PacketReplyMessage::~MG3PacketReplyMessage()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3DataReplyMessage::~MG3DataReplyMessage()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3MSERequestMessage::MG3MSERequestMessage()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3PacketRequestMessage::~MG3PacketRequestMessage()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3MessageReader::MG3MessageReader(LizardTech::LTIOStreamInf)' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3PlaneRangeDecoder::done()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3MessageReader::skipMessageBody()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3VersionReplyMessage::~MG3VersionReplyMessage()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3PlaneRangeDecoder::begin()' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference to `LizardTech::MG3VersionReplyMessage::MG3VersionReplyMessage(LizardTech::MG3Version const*)' /root/gdal/Geo_ESDK-7.0.0.2167/lib/Release/libltidsdk.so: undefined reference
[gdal-dev] Strange effect in gdalwarp output
This question was posted originally at http://gis.stackexchange.com/questions/154959/strange-effect-in-gdalwarp-output http://gis.stackexchange.com/questions/154959/strange-effect-in-gdalwarp-output but I did not get any helpful response. Here is the problem: I am using gdalwarp in python to extract and re-project reflectance bands from MODIS level 1B (MOD021km). The command that I am using is the following: / gdalwarp -of GTIFF -tps -t_srs EPSG:4326 -tr 0.01 0.01 -r bilinear -overwrite HDF4_EOS:EOS_SWATH:C:\tmp\MYD021KM.A2007094.0935.006.2012075055042.hdf:MODIS_SWATH_Type_L1B:EV_500_Aggr1km_RefSB C:\tmp\Output.tif / It converts the hdf subdataset without any problem but the output file seems to have some sort of artifact, specially close to the edges. (See below) http://osgeo-org.1560.x6.nabble.com/file/n5216470/gdalwarp.jpg I converted the same data using Modis Conversion Toolkit (MCTK) and it seems to be much better. (Below) http://osgeo-org.1560.x6.nabble.com/file/n5216470/MCTK.jpg I tried different resampling method and different output projection but still the same results! Is there anyone having this issue with gdalwarp? P.S. The data can be downloaded from this address: ftp://ladsweb.nascom.nasa.gov/allData/6/MYD021KM/2007/094/MYD021KM.A2007094.0935.006.2012075055042.hdf -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Strange-effect-in-gdalwarp-output-tp5216470.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Strange effect in gdalwarp output
Monobakht, Probably due to the bow-tie effect of the MODIS scanning sensor. gdalwarp cannot currently deal with that correctly. Discussed recently in this thread: http://osgeo-org.1560.x6.nabble.com/gdal-dev-gdalwarp-problems-with-MODIS-L1B-td5206583.html Best regards, Even This question was posted originally at http://gis.stackexchange.com/questions/154959/strange-effect-in-gdalwarp-ou tput http://gis.stackexchange.com/questions/154959/strange-effect-in-gdalwarp- output but I did not get any helpful response. Here is the problem: I am using gdalwarp in python to extract and re-project reflectance bands from MODIS level 1B (MOD021km). The command that I am using is the following: / gdalwarp -of GTIFF -tps -t_srs EPSG:4326 -tr 0.01 0.01 -r bilinear -overwrite HDF4_EOS:EOS_SWATH:C:\tmp\MYD021KM.A2007094.0935.006.2012075055042.hdf:MO DIS_SWATH_Type_L1B:EV_500_Aggr1km_RefSB C:\tmp\Output.tif / It converts the hdf subdataset without any problem but the output file seems to have some sort of artifact, specially close to the edges. (See below) http://osgeo-org.1560.x6.nabble.com/file/n5216470/gdalwarp.jpg I converted the same data using Modis Conversion Toolkit (MCTK) and it seems to be much better. (Below) http://osgeo-org.1560.x6.nabble.com/file/n5216470/MCTK.jpg I tried different resampling method and different output projection but still the same results! Is there anyone having this issue with gdalwarp? P.S. The data can be downloaded from this address: ftp://ladsweb.nascom.nasa.gov/allData/6/MYD021KM/2007/094/MYD021KM.A2007094 .0935.006.2012075055042.hdf -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Strange-effect-in-gdalwarp-output-tp52 16470.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ 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
Re: [gdal-dev] Strange effect in gdalwarp output
Thank you Even for your reply. I am actually not a professional gdal user, but looking at the thread that you posted I think the problem here is slightly different. Georegistration accuracy of gdalwarp result is perfectly fine, even better that MCTK result, and the bowtie effect is not present. I think it is a problem in resampling step that causes this artefact! Is that what you meant? Regards Mohamad Even Rouault-2 wrote Monobakht, Probably due to the bow-tie effect of the MODIS scanning sensor. gdalwarp cannot currently deal with that correctly. Discussed recently in this thread: http://osgeo-org.1560.x6.nabble.com/gdal-dev-gdalwarp-problems-with-MODIS-L1B-td5206583.html Best regards, Even This question was posted originally at http://gis.stackexchange.com/questions/154959/strange-effect-in-gdalwarp-ou tput lt;http://gis.stackexchange.com/questions/154959/strange-effect-in-gdalwarp- gt; output but I did not get any helpful response. Here is the problem: I am using gdalwarp in python to extract and re-project reflectance bands from MODIS level 1B (MOD021km). The command that I am using is the following: / gdalwarp -of GTIFF -tps -t_srs EPSG:4326 -tr 0.01 0.01 -r bilinear -overwrite HDF4_EOS:EOS_SWATH:C:\tmp\MYD021KM.A2007094.0935.006.2012075055042.hdf:MO DIS_SWATH_Type_L1B:EV_500_Aggr1km_RefSB C:\tmp\Output.tif / It converts the hdf subdataset without any problem but the output file seems to have some sort of artifact, specially close to the edges. (See below) lt;http://osgeo-org.1560.x6.nabble.com/file/n5216470/gdalwarp.jpggt; I converted the same data using Modis Conversion Toolkit (MCTK) and it seems to be much better. (Below) lt;http://osgeo-org.1560.x6.nabble.com/file/n5216470/MCTK.jpggt; I tried different resampling method and different output projection but still the same results! Is there anyone having this issue with gdalwarp? P.S. The data can be downloaded from this address: ftp://ladsweb.nascom.nasa.gov/allData/6/MYD021KM/2007/094/MYD021KM.A2007094 .0935.006.2012075055042.hdf -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Strange-effect-in-gdalwarp-output-tp52 16470.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@.osgeo http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@.osgeo http://lists.osgeo.org/mailman/listinfo/gdal-dev -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Strange-effect-in-gdalwarp-output-tp5216470p5216483.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Strange effect in gdalwarp output
Dear Mohamad, I think Even is right, and it is the bowtie-effect. The file you are trying to warp is still a 'swath', therefore it still contains the bowtie-effect. You can see that the right side of the image looks worse, the viewing angles are greatest at that edge, and the overlap between sensor scans is at its largest. At nadir, more to the left of the image, it already looks much better. I don't know the MCTK, but that image also doesn't look great, although better. You could use dedicated tools such as MRTSwath to resample the image to a regular grid. Or use something like PyResample (if you work with Python). https://lpdaac.usgs.gov/tools/modis_reprojection_tool_swath https://github.com/pytroll/pyresample (part of PyTroll: http://www.pytroll.org/) Once you have a regular grid, all GDAL tools and function will work fine. Gdalwarp and the other utilities will work directly with the higher level MODIS products, which are gridded to a sinusoidal grid. Regards, Rutger -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Strange-effect-in-gdalwarp-output-tp5216470p5216487.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] how to build dwg driver?
Hi, I am having a hard time trying to build the DWG driver (VS10x64). Reading from nmake.opt it seems like there are two SDK we can use. I could not find the DWGDirect SDK for download, so I am trying to use TX_DSK_4.1.01.0.0. Compilation goes well but I am getting several missing symbols during the linkage. Does anybody have experience building that driver could give some advice? Thanks a lot. Ivan ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual class OdSmartPtrclass OdStreamBuf __cdecl ExSystemServices::createFile(class OdString const ,enum Oda::FileAccessMode,en um Oda::FileShareMode,enum Oda::FileCreationDisposition) (?createFile@ExSystemServices@@UEAA?AV?$OdSmartPtr@VOdStreamBufAEBVOdString@@W4FileAccessMode@Oda@@W4FileShareMode@5@W4FileCreationDisposit ion@5@@Z) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual bool __cdecl ExSystemServices::accessFile(class OdString const ,int) (?accessFile@ExSystemServices@@UEAA_NAEBVOdString@@H @Z) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual __int64 __cdecl ExSystemServices::getFileCTime(class OdString const ) (?getFileCTime@ExSystemServices@@UEAA_JAEBVOdString @@@Z) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual __int64 __cdecl ExSystemServices::getFileMTime(class OdString const ) (?getFileMTime@ExSystemServices@@UEAA_JAEBVOdString @@@Z) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual __int64 __cdecl ExSystemServices::getFileSize(class OdString const ) (?getFileSize@ExSystemServices@@UEAA_JAEBVOdString@@ @Z) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual class OdString __cdecl ExSystemServices::formatMessage(unsigned int,char * *) (?formatMessage@ExSystemServices@@UEAA?AVOdS tring@@IPEAPEAD@Z) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual enum OdCodePageId __cdecl ExSystemServices::systemCodePage(void)const (?systemCodePage@ExSystemServices@@UEBA?AW4OdCodePa geId@@XZ) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual enum OdResult __cdecl ExSystemServices::initModelerLibrary(void) (?initModelerLibrary@ExSystemServices@@UEAA?AW4OdResult@@ XZ) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual enum OdResult __cdecl ExSystemServices::uninitModelerLibrary(void) (?uninitModelerLibrary@ExSystemServices@@UEAA?AW4OdResu lt@@XZ) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual class OdDbHostAppProgressMeter * __cdecl ExHostAppServices::newProgressMeter(void) (?newProgressMeter@ExHostAppServices@@U EAAPEAVOdDbHostAppProgressMeter@@XZ) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual void __cdecl ExHostAppServices::releaseProgressMeter(class OdDbHostAppProgressMeter *) (?releaseProgressMeter@ExHostAppSer vices@@UEAAXPEAVOdDbHostAppProgressMeter@@@Z) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual bool __cdecl ExHostAppServices::ttfFileNameByDescriptor(class OdTtfDescriptor const ,class OdString ) (?ttfFileNameByDes criptor@ExHostAppServices@@UEAA_NAEBVOdTtfDescriptor@@AEAVOdString@@@Z) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual class OdSmartPtrclass OdGsDevice __cdecl ExHostAppServices::gsBitmapDevice(class OdRxObject *,class OdRxObject *,unsigned long) (?gsBitmapDevice@ExHostAppServices@@UEAA?AV?$OdSmartPtr@VOdGsDevicePEAVOdRxObject@@0K@Z) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual class OdSmartPtrclass OdDbDatabase __cdecl ExHostAppServices::readFile(class OdString const ,bool,bool,enum Oda::FileSha reMode,class OdString const ) (?readFile@ExHostAppServices@@UEAA?AV?$OdSmartPtr@VOdDbDatabaseAEBVOdString@@_N1W4FileShareMode@Oda@@0@Z) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual class OdHatchPatternManager * __cdecl ExHostAppServices::patternManager(void) (?patternManager@ExHostAppServices@@UEAAPEAV OdHatchPatternManager@@XZ) ogrdwgdriver.obj : error LNK2001: unresolved external symbol private: virtual class OdDbKey * __cdecl OdDbHostAppServices2::key(void)const (?key@OdDbHostAppServices2@@EEBAPEAVOdDbKey@@XZ) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual void __cdecl ExHostAppServices::start(class OdString const ) (?start@ExHostAppServices@@UEAAXAEBVOdString@@@Z) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual void __cdecl ExHostAppServices::stop(void) (?stop@ExHostAppServices@@UEAAXXZ) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual void __cdecl ExHostAppServices::meterProgress(void) (?meterProgress@ExHostAppServices@@UEAAXXZ) ogrdwgdriver.obj : error LNK2001: unresolved external symbol public: virtual void __cdecl ExHostAppServices::setLimit(int)
Re: [gdal-dev] Motion: Adopt FRC48: Geographical networks support
Hi everybody, Just a friendly remainder about motion adopt RFC48. Geographical networks support. Now we have +2 (+1 from me as proposer and +1 from Even). Formally the RFC can be adopted, but maybe there is some disagreement or some valuable comments. Best regards, Dmitry ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt FRC48: Geographical networks support
On Wednesday 22 July 2015 17:03:38 Dmitry Baryshnikov wrote: Hi everybody, Just a friendly remainder about motion adopt RFC48. Geographical networks support. Now we have +2 (+1 from me as proposer and +1 from Even). Formally the RFC can be adopted, but maybe there is some disagreement or some valuable comments. Hum, actually I'm not sure if we shouldn't need at least another +1 from a PSC member. The interpretation of the rules at https://trac.osgeo.org/gdal/wiki/rfc1_pmc; is not completely clear to me in the case the proposer is not a PSC member. 1. Proposals are written up and submitted on the gdal-dev mailing list for discussion and voting, by any interested party, not just committee members. 6. Anyone may comment on proposals on the list, but only members of the Project Management Committee's votes will be counted. 7. A proposal will be accepted if it receives +2 (including the proposer) and no vetos (-1). Best regards, Dmitry ___ 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
